Mailing List Archive

restlet dependencies
Just FYI: can't get PR builds on github to work recently because of this:

> Could not resolve all files for configuration ':solr:core:compileClasspath'.
350 > Could not download org.restlet.ext.servlet-2.4.3.jar
(org.restlet.jee:org.restlet.ext.servlet:2.4.3)
351 > Could not get resource
'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.restlet.ext.servlet-2.4.3.jar'.
352 > Could not GET
'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.restlet.ext.servlet-2.4.3.jar'.
353 > Connection reset
354 > Could not download org.restlet-2.4.3.jar
(org.restlet.jee:org.restlet:2.4.3)
355 > Could not get resource
'https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.jar'.
356 > Could not GET
'https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.jar'.
357 > Connection reset

D.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: restlet dependencies [ In reply to ]
Sorry, afk, but I heard (*hearsay*) that restlet is also on maven central
these days. Can we confirm and switch to that? Sorry, if that's not the
case.

On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <dawid.weiss@gmail.com> wrote:

> Just FYI: can't get PR builds on github to work recently because of this:
>
> > Could not resolve all files for configuration
> ':solr:core:compileClasspath'.
> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
> 351 > Could not get resource
> '
> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.restlet.ext.servlet-2.4.3.jar
> '.
> 352 > Could not GET
> '
> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.restlet.ext.servlet-2.4.3.jar
> '.
> 353 > Connection reset
> 354 > Could not download org.restlet-2.4.3.jar
> (org.restlet.jee:org.restlet:2.4.3)
> 355 > Could not get resource
> '
> https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.jar
> '.
> 356 > Could not GET
> '
> https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.jar
> '.
> 357 > Connection reset
>
> D.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: restlet dependencies [ In reply to ]
https://mvnrepository.com/artifact/org.restlet.jee/org.restlet.ext.servlet

On Fri, 18 Sep, 2020, 2:15 pm Ishan Chattopadhyaya, <
ichattopadhyaya@gmail.com> wrote:

> Sorry, afk, but I heard (*hearsay*) that restlet is also on maven central
> these days. Can we confirm and switch to that? Sorry, if that's not the
> case.
>
> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <dawid.weiss@gmail.com> wrote:
>
>> Just FYI: can't get PR builds on github to work recently because of this:
>>
>> > Could not resolve all files for configuration
>> ':solr:core:compileClasspath'.
>> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>> 351 > Could not get resource
>> '
>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.restlet.ext.servlet-2.4.3.jar
>> '.
>> 352 > Could not GET
>> '
>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.restlet.ext.servlet-2.4.3.jar
>> '.
>> 353 > Connection reset
>> 354 > Could not download org.restlet-2.4.3.jar
>> (org.restlet.jee:org.restlet:2.4.3)
>> 355 > Could not get resource
>> '
>> https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.jar
>> '.
>> 356 > Could not GET
>> '
>> https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.jar
>> '.
>> 357 > Connection reset
>>
>> D.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
Re: restlet dependencies [ In reply to ]
I don't think it is, sadly.
https://repo1.maven.org/maven2/org/restlet

The link you provided (mvnrepository) aggregates from several maven
repositories.


D.

On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
<ichattopadhyaya@gmail.com> wrote:
>
> Sorry, afk, but I heard (*hearsay*) that restlet is also on maven central these days. Can we confirm and switch to that? Sorry, if that's not the case.
>
> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <dawid.weiss@gmail.com> wrote:
>>
>> Just FYI: can't get PR builds on github to work recently because of this:
>>
>> > Could not resolve all files for configuration ':solr:core:compileClasspath'.
>> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>> 351 > Could not get resource
>> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.restlet.ext.servlet-2.4.3.jar'.
>> 352 > Could not GET
>> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.restlet.ext.servlet-2.4.3.jar'.
>> 353 > Connection reset
>> 354 > Could not download org.restlet-2.4.3.jar
>> (org.restlet.jee:org.restlet:2.4.3)
>> 355 > Could not get resource
>> 'https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.jar'.
>> 356 > Could not GET
>> 'https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.jar'.
>> 357 > Connection reset
>>
>> D.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: restlet dependencies [ In reply to ]
This sounds vaguely familiar. "http works, https does not work" and https://issues.apache.org/jira/browse/SOLR-13756 possibly related?

From: dev@lucene.apache.org At: 09/18/20 10:01:29To: dev@lucene.apache.org
Subject: Re: restlet dependencies

I don't think it is, sadly.
https://repo1.maven.org/maven2/org/restlet

The link you provided (mvnrepository) aggregates from several maven
repositories.


D.

On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
<ichattopadhyaya@gmail.com> wrote:
>
> Sorry, afk, but I heard (*hearsay*) that restlet is also on maven central
these days. Can we confirm and switch to that? Sorry, if that's not the case.
>
> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <dawid.weiss@gmail.com> wrote:
>>
>> Just FYI: can't get PR builds on github to work recently because of this:
>>
>> > Could not resolve all files for configuration
':solr:core:compileClasspath'.
>> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>> 351 > Could not get resource
>>
'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
tlet.ext.servlet-2.4.3.jar'.
>> 352 > Could not GET
>>
'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
tlet.ext.servlet-2.4.3.jar'.
>> 353 > Connection reset
>> 354 > Could not download org.restlet-2.4.3.jar
>> (org.restlet.jee:org.restlet:2.4.3)
>> 355 > Could not get resource
>>
'https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
ar'.
>> 356 > Could not GET
>>
'https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
2.4.3.jar'.
>> 357 > Connection reset
>>
>> D.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: restlet dependencies [ In reply to ]
I don't think it's http/https - I believe restlet repository simply
bans github servers because of excessive traffic? These URLs work for
me locally...

Dawid

On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
LONDON) <cpoerschke@bloomberg.net> wrote:
>
> This sounds vaguely familiar. "http works, https does not work" and https://issues.apache.org/jira/browse/SOLR-13756 possibly related?
>
> From: dev@lucene.apache.org At: 09/18/20 10:01:29
> To: dev@lucene.apache.org
> Subject: Re: restlet dependencies
>
> I don't think it is, sadly.
> https://repo1.maven.org/maven2/org/restlet
>
> The link you provided (mvnrepository) aggregates from several maven
> repositories.
>
>
> D.
>
> On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
> <ichattopadhyaya@gmail.com> wrote:
> >
> > Sorry, afk, but I heard (*hearsay*) that restlet is also on maven central
> these days. Can we confirm and switch to that? Sorry, if that's not the case.
> >
> > On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <dawid.weiss@gmail.com> wrote:
> >>
> >> Just FYI: can't get PR builds on github to work recently because of this:
> >>
> >> > Could not resolve all files for configuration
> ':solr:core:compileClasspath'.
> >> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
> >> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
> >> 351 > Could not get resource
> >>
> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
> tlet.ext.servlet-2.4.3.jar'.
> >> 352 > Could not GET
> >>
> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
> tlet.ext.servlet-2.4.3.jar'.
> >> 353 > Connection reset
> >> 354 > Could not download org.restlet-2.4.3.jar
> >> (org.restlet.jee:org.restlet:2.4.3)
> >> 355 > Could not get resource
> >>
> 'https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
> ar'.
> >> 356 > Could not GET
> >>
> 'https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
> 2.4.3.jar'.
> >> 357 > Connection reset
> >>
> >> D.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: restlet dependencies [ In reply to ]
I was thinking the same. Because GitHub does not cache the downloaded artifacts like our jenkins servers.

It seems to run it in a new VM or container every time, so it downloads all artifacts. If I were Talend, I'd also block this.

Uwe

Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <dawid.weiss@gmail.com>:
>I don't think it's http/https - I believe restlet repository simply
>bans github servers because of excessive traffic? These URLs work for
>me locally...
>
>Dawid
>
>On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
>LONDON) <cpoerschke@bloomberg.net> wrote:
>>
>> This sounds vaguely familiar. "http works, https does not work" and
>https://issues.apache.org/jira/browse/SOLR-13756 possibly related?
>>
>> From: dev@lucene.apache.org At: 09/18/20 10:01:29
>> To: dev@lucene.apache.org
>> Subject: Re: restlet dependencies
>>
>> I don't think it is, sadly.
>> https://repo1.maven.org/maven2/org/restlet
>>
>> The link you provided (mvnrepository) aggregates from several maven
>> repositories.
>>
>>
>> D.
>>
>> On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
>> <ichattopadhyaya@gmail.com> wrote:
>> >
>> > Sorry, afk, but I heard (*hearsay*) that restlet is also on maven
>central
>> these days. Can we confirm and switch to that? Sorry, if that's not
>the case.
>> >
>> > On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <dawid.weiss@gmail.com>
>wrote:
>> >>
>> >> Just FYI: can't get PR builds on github to work recently because
>of this:
>> >>
>> >> > Could not resolve all files for configuration
>> ':solr:core:compileClasspath'.
>> >> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>> >> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>> >> 351 > Could not get resource
>> >>
>>
>'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>> tlet.ext.servlet-2.4.3.jar'.
>> >> 352 > Could not GET
>> >>
>>
>'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>> tlet.ext.servlet-2.4.3.jar'.
>> >> 353 > Connection reset
>> >> 354 > Could not download org.restlet-2.4.3.jar
>> >> (org.restlet.jee:org.restlet:2.4.3)
>> >> 355 > Could not get resource
>> >>
>>
>'https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
>> ar'.
>> >> 356 > Could not GET
>> >>
>>
>'https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
>> 2.4.3.jar'.
>> >> 357 > Connection reset
>> >>
>> >> D.
>> >>
>> >>
>---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>For additional commands, e-mail: dev-help@lucene.apache.org

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de
Re: restlet dependencies [ In reply to ]
If I were talend, I'd immediately start publishing to maven central. If I
were the developer who built the schema APIs, I would never have used
restlet to begin with.

On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, <uwe@thetaphi.de> wrote:

> I was thinking the same. Because GitHub does not cache the downloaded
> artifacts like our jenkins servers.
>
> It seems to run it in a new VM or container every time, so it downloads
> all artifacts. If I were Talend, I'd also block this.
>
> Uwe
>
> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
> dawid.weiss@gmail.com>:
>>
>> I don't think it's http/https - I believe restlet repository simply
>> bans github servers because of excessive traffic? These URLs work for
>> me locally...
>>
>> Dawid
>>
>> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
>> LONDON) <cpoerschke@bloomberg.net> wrote:
>>
>>>
>>> This sounds vaguely familiar. "http works, https does not work" and https://issues.apache.org/jira/browse/SOLR-13756 possibly related?
>>>
>>> From: dev@lucene.apache.org At: 09/18/20 10:01:29
>>> To: dev@lucene.apache.org
>>> Subject: Re: restlet dependencies
>>>
>>> I don't think it is, sadly.
>>> https://repo1.maven.org/maven2/org/restlet
>>>
>>> The link you provided (mvnrepository) aggregates from several maven
>>> repositories.
>>>
>>>
>>> D.
>>>
>>> On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
>>> <ichattopadhyaya@gmail.com> wrote:
>>>
>>>>
>>>> Sorry, afk, but I heard (*hearsay*) that restlet is also on maven central
>>>>
>>> these days. Can we confirm and switch to that? Sorry, if that's not the case.
>>>
>>>>
>>>> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <dawid.weiss@gmail.com> wrote:
>>>>
>>>>>
>>>>> Just FYI: can't get PR builds on github to work recently because of this:
>>>>>
>>>>> Could not resolve all files for configuration
>>>>>>
>>>>> ':solr:core:compileClasspath'.
>>>
>>>> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>>>>> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>>>>> 351 > Could not get resource
>>>>>
>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>> tlet.ext.servlet-2.4.3.jar'.
>>>
>>>> 352 > Could not GET
>>>>>
>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>> tlet.ext.servlet-2.4.3.jar'.
>>>
>>>> 353 > Connection reset
>>>>> 354 > Could not download org.restlet-2.4.3.jar
>>>>> (org.restlet.jee:org.restlet:2.4.3)
>>>>> 355 > Could not get resource
>>>>>
>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
>>> ar'.
>>>
>>>> 356 > Could not GET
>>>>>
>>>>> 'https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
>>> 2.4.3.jar'.
>>>
>>>> 357 > Connection reset
>>>>>
>>>>> D.
>>>>> ------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>> ------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>>> ------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de
>
Re: restlet dependencies [ In reply to ]
Haha.

In fact schema APIs don't use restlet. Only the managed resources use it

On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
ichattopadhyaya@gmail.com> wrote:

> If I were talend, I'd immediately start publishing to maven central. If I
> were the developer who built the schema APIs, I would never have used
> restlet to begin with.
>
> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, <uwe@thetaphi.de> wrote:
>
>> I was thinking the same. Because GitHub does not cache the downloaded
>> artifacts like our jenkins servers.
>>
>> It seems to run it in a new VM or container every time, so it downloads
>> all artifacts. If I were Talend, I'd also block this.
>>
>> Uwe
>>
>> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
>> dawid.weiss@gmail.com>:
>>>
>>> I don't think it's http/https - I believe restlet repository simply
>>> bans github servers because of excessive traffic? These URLs work for
>>> me locally...
>>>
>>> Dawid
>>>
>>> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
>>> LONDON) <cpoerschke@bloomberg.net> wrote:
>>>
>>>>
>>>> This sounds vaguely familiar. "http works, https does not work" and https://issues.apache.org/jira/browse/SOLR-13756 possibly related?
>>>>
>>>> From: dev@lucene.apache.org At: 09/18/20 10:01:29
>>>> To: dev@lucene.apache.org
>>>> Subject: Re: restlet dependencies
>>>>
>>>> I don't think it is, sadly.
>>>> https://repo1.maven.org/maven2/org/restlet
>>>>
>>>> The link you provided (mvnrepository) aggregates from several maven
>>>> repositories.
>>>>
>>>>
>>>> D.
>>>>
>>>> On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
>>>> <ichattopadhyaya@gmail.com> wrote:
>>>>
>>>>>
>>>>> Sorry, afk, but I heard (*hearsay*) that restlet is also on maven central
>>>>>
>>>> these days. Can we confirm and switch to that? Sorry, if that's not the case.
>>>>
>>>>>
>>>>> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <dawid.weiss@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> Just FYI: can't get PR builds on github to work recently because of this:
>>>>>>
>>>>>> Could not resolve all files for configuration
>>>>>>>
>>>>>> ':solr:core:compileClasspath'.
>>>>
>>>>> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>>>>>> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>>>>>> 351 > Could not get resource
>>>>>>
>>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>>> tlet.ext.servlet-2.4.3.jar'.
>>>>
>>>>> 352 > Could not GET
>>>>>>
>>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>>> tlet.ext.servlet-2.4.3.jar'.
>>>>
>>>>> 353 > Connection reset
>>>>>> 354 > Could not download org.restlet-2.4.3.jar
>>>>>> (org.restlet.jee:org.restlet:2.4.3)
>>>>>> 355 > Could not get resource
>>>>>>
>>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
>>>> ar'.
>>>>
>>>>> 356 > Could not GET
>>>>>>
>>>>>> 'https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
>>>> 2.4.3.jar'.
>>>>
>>>>> 357 > Connection reset
>>>>>>
>>>>>> D.
>>>>>> ------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>
>>>>>> ------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>>
>>>> ------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>> --
>> Uwe Schindler
>> Achterdiek 19, 28357 Bremen
>> https://www.thetaphi.de
>>
>
Re: restlet dependencies [ In reply to ]
Do we have a community blessed alternative to restlet already?

> On Sep 20, 2020, at 9:40 AM, Noble Paul <noble.paul@gmail.com> wrote:
>
> Haha.
>
> In fact schema APIs don't use restlet. Only the managed resources use it
>
> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com>> wrote:
> If I were talend, I'd immediately start publishing to maven central. If I were the developer who built the schema APIs, I would never have used restlet to begin with.
>
> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, <uwe@thetaphi.de <mailto:uwe@thetaphi.de>> wrote:
> I was thinking the same. Because GitHub does not cache the downloaded artifacts like our jenkins servers.
>
> It seems to run it in a new VM or container every time, so it downloads all artifacts. If I were Talend, I'd also block this.
>
> Uwe
>
> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <dawid.weiss@gmail.com <mailto:dawid.weiss@gmail.com>>:
> I don't think it's http/https - I believe restlet repository simply
> bans github servers because of excessive traffic? These URLs work for
> me locally...
>
> Dawid
>
> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
> LONDON) <cpoerschke@bloomberg.net <mailto:cpoerschke@bloomberg.net>> wrote:
>
> This sounds vaguely familiar. "http works, https does not work" and https://issues.apache.org/jira/browse/SOLR-13756 <https://issues.apache.org/jira/browse/SOLR-13756> possibly related?
>
> From: dev@lucene.apache.org <mailto:dev@lucene.apache.org> At: 09/18/20 10:01:29
> To: dev@lucene.apache.org <mailto:dev@lucene.apache.org>
> Subject: Re: restlet dependencies
>
> I don't think it is, sadly.
> https://repo1.maven.org/maven2/org/restlet <https://repo1.maven.org/maven2/org/restlet>
>
> The link you provided (mvnrepository) aggregates from several maven
> repositories.
>
>
> D.
>
> On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
> <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com>> wrote:
>
> Sorry, afk, but I heard (*hearsay*) that restlet is also on maven central
> these days. Can we confirm and switch to that? Sorry, if that's not the case.
>
> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <dawid.weiss@gmail.com <mailto:dawid.weiss@gmail.com>> wrote:
>
> Just FYI: can't get PR builds on github to work recently because of this:
>
> Could not resolve all files for configuration
> ':solr:core:compileClasspath'.
> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
> 351 > Could not get resource
>
> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res <https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res>
> tlet.ext.servlet-2.4.3.jar'.
> 352 > Could not GET
>
> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res <https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res>
> tlet.ext.servlet-2.4.3.jar'.
> 353 > Connection reset
> 354 > Could not download org.restlet-2.4.3.jar
> (org.restlet.jee:org.restlet:2.4.3)
> 355 > Could not get resource
>
> 'https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j <https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j>
> ar'.
> 356 > Could not GET
>
> 'https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet- <https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet->
> 2.4.3.jar'.
> 357 > Connection reset
>
> D.
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
>
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
>
>
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
>
>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de <https://www.thetaphi.de/>
_______________________
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal>
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
Re: restlet dependencies [ In reply to ]
Restlet again!!!!!!!



Joel Bernstein
http://joelsolr.blogspot.com/


On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <epugh@opensourceconnections.com>
wrote:

> Do we have a community blessed alternative to restlet already?
>
> On Sep 20, 2020, at 9:40 AM, Noble Paul <noble.paul@gmail.com> wrote:
>
> Haha.
>
> In fact schema APIs don't use restlet. Only the managed resources use it
>
> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
>
>> If I were talend, I'd immediately start publishing to maven central. If I
>> were the developer who built the schema APIs, I would never have used
>> restlet to begin with.
>>
>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, <uwe@thetaphi.de> wrote:
>>
>>> I was thinking the same. Because GitHub does not cache the downloaded
>>> artifacts like our jenkins servers.
>>>
>>> It seems to run it in a new VM or container every time, so it downloads
>>> all artifacts. If I were Talend, I'd also block this.
>>>
>>> Uwe
>>>
>>> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
>>> dawid.weiss@gmail.com>:
>>>>
>>>> I don't think it's http/https - I believe restlet repository simply
>>>> bans github servers because of excessive traffic? These URLs work for
>>>> me locally...
>>>>
>>>> Dawid
>>>>
>>>> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
>>>> LONDON) <cpoerschke@bloomberg.net> wrote:
>>>>
>>>>>
>>>>> This sounds vaguely familiar. "http works, https does not work" and https://issues.apache.org/jira/browse/SOLR-13756 possibly related?
>>>>>
>>>>> From: dev@lucene.apache.org At: 09/18/20 10:01:29
>>>>> To: dev@lucene.apache.org
>>>>> Subject: Re: restlet dependencies
>>>>>
>>>>> I don't think it is, sadly.
>>>>> https://repo1.maven.org/maven2/org/restlet
>>>>>
>>>>> The link you provided (mvnrepository) aggregates from several maven
>>>>> repositories.
>>>>>
>>>>>
>>>>> D.
>>>>>
>>>>> On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
>>>>> <ichattopadhyaya@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> Sorry, afk, but I heard (*hearsay*) that restlet is also on maven central
>>>>>>
>>>>> these days. Can we confirm and switch to that? Sorry, if that's not the case.
>>>>>
>>>>>>
>>>>>> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <dawid.weiss@gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>> Just FYI: can't get PR builds on github to work recently because of this:
>>>>>>>
>>>>>>> Could not resolve all files for configuration
>>>>>>>>
>>>>>>> ':solr:core:compileClasspath'.
>>>>>
>>>>>> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>>>>>>> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>>>>>>> 351 > Could not get resource
>>>>>>>
>>>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>>>> tlet.ext.servlet-2.4.3.jar'.
>>>>>
>>>>>> 352 > Could not GET
>>>>>>>
>>>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>>>> tlet.ext.servlet-2.4.3.jar'.
>>>>>
>>>>>> 353 > Connection reset
>>>>>>> 354 > Could not download org.restlet-2.4.3.jar
>>>>>>> (org.restlet.jee:org.restlet:2.4.3)
>>>>>>> 355 > Could not get resource
>>>>>>>
>>>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
>>>>> ar'.
>>>>>
>>>>>> 356 > Could not GET
>>>>>>>
>>>>>>> 'https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
>>>>> 2.4.3.jar'.
>>>>>
>>>>>> 357 > Connection reset
>>>>>>>
>>>>>>> D.
>>>>>>> ------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>
>>>>>>> ------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>>
>>>>> ------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>>
>>> --
>>> Uwe Schindler
>>> Achterdiek 19, 28357 Bremen
>>> https://www.thetaphi.de
>>>
>>
> _______________________
> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
> | http://www.opensourceconnections.com | My Free/Busy
> <http://tinyurl.com/eric-cal>
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
> This e-mail and all contents, including attachments, is considered to be
> Company Confidential unless explicitly stated otherwise, regardless
> of whether attachments are marked as such.
>
>
Re: restlet dependencies [ In reply to ]
We should deprecate that feature and remove restlet dependency altogether

On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein <joelsolr@gmail.com> wrote:
>
> Restlet again!!!!!!!
>
>
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
>
> On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <epugh@opensourceconnections.com> wrote:
>>
>> Do we have a community blessed alternative to restlet already?
>>
>> On Sep 20, 2020, at 9:40 AM, Noble Paul <noble.paul@gmail.com> wrote:
>>
>> Haha.
>>
>> In fact schema APIs don't use restlet. Only the managed resources use it
>>
>> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <ichattopadhyaya@gmail.com> wrote:
>>>
>>> If I were talend, I'd immediately start publishing to maven central. If I were the developer who built the schema APIs, I would never have used restlet to begin with.
>>>
>>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, <uwe@thetaphi.de> wrote:
>>>>
>>>> I was thinking the same. Because GitHub does not cache the downloaded artifacts like our jenkins servers.
>>>>
>>>> It seems to run it in a new VM or container every time, so it downloads all artifacts. If I were Talend, I'd also block this.
>>>>
>>>> Uwe
>>>>
>>>> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <dawid.weiss@gmail.com>:
>>>>>
>>>>> I don't think it's http/https - I believe restlet repository simply
>>>>> bans github servers because of excessive traffic? These URLs work for
>>>>> me locally...
>>>>>
>>>>> Dawid
>>>>>
>>>>> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
>>>>> LONDON) <cpoerschke@bloomberg.net> wrote:
>>>>>>
>>>>>>
>>>>>> This sounds vaguely familiar. "http works, https does not work" and https://issues.apache.org/jira/browse/SOLR-13756 possibly related?
>>>>>>
>>>>>> From: dev@lucene.apache.org At: 09/18/20 10:01:29
>>>>>> To: dev@lucene.apache.org
>>>>>> Subject: Re: restlet dependencies
>>>>>>
>>>>>> I don't think it is, sadly.
>>>>>> https://repo1.maven.org/maven2/org/restlet
>>>>>>
>>>>>> The link you provided (mvnrepository) aggregates from several maven
>>>>>> repositories.
>>>>>>
>>>>>>
>>>>>> D.
>>>>>>
>>>>>> On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
>>>>>> <ichattopadhyaya@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Sorry, afk, but I heard (*hearsay*) that restlet is also on maven central
>>>>>>
>>>>>> these days. Can we confirm and switch to that? Sorry, if that's not the case.
>>>>>>>
>>>>>>>
>>>>>>> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <dawid.weiss@gmail.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Just FYI: can't get PR builds on github to work recently because of this:
>>>>>>>>
>>>>>>>>> Could not resolve all files for configuration
>>>>>>
>>>>>> ':solr:core:compileClasspath'.
>>>>>>>>
>>>>>>>> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>>>>>>>> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>>>>>>>> 351 > Could not get resource
>>>>>>>>
>>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>>>>> tlet.ext.servlet-2.4.3.jar'.
>>>>>>>>
>>>>>>>> 352 > Could not GET
>>>>>>>>
>>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>>>>> tlet.ext.servlet-2.4.3.jar'.
>>>>>>>>
>>>>>>>> 353 > Connection reset
>>>>>>>> 354 > Could not download org.restlet-2.4.3.jar
>>>>>>>> (org.restlet.jee:org.restlet:2.4.3)
>>>>>>>> 355 > Could not get resource
>>>>>>>>
>>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
>>>>>> ar'.
>>>>>>>>
>>>>>>>> 356 > Could not GET
>>>>>>>>
>>>>>> 'https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
>>>>>> 2.4.3.jar'.
>>>>>>>>
>>>>>>>> 357 > Connection reset
>>>>>>>>
>>>>>>>> D.
>>>>>>>> ________________________________
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>>
>>>>>> ________________________________
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>
>>>>>>
>>>>> ________________________________
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>
>>>> --
>>>> Uwe Schindler
>>>> Achterdiek 19, 28357 Bremen
>>>> https://www.thetaphi.de
>>
>>
>> _______________________
>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
>>


--
-----------------------------------------------------
Noble Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: restlet dependencies [ In reply to ]
I agree we should deprecate the managed resources feature, it was the first
thing I was asked to build by LW nearly 7 years ago, before I was a
committer. Restlet was already in place and I built on top of that, not
sure who introduced it originally (nor do I care). Clearly from the vantage
point of looking back, JAX-RS and Jersey won the day with REST in Java but
that simply wasn't the case back then. What's important is how we move
forward vs. bestowing judgement backed by wisdom of hindsight on decisions
made many years ago.

In the short term, does Apache have an Artifactory (or similar) where we
can host the Restlet dependencies for Github to pull them from? If not,
then we can port the code that's using Restlet over to using JAX-RS /
Jersey. Personally I'd prefer we remove Managed Resources support from 9
instead of porting the Restlet code but I don't know if 9 is too soon from
a deprecation stand point?

Tim


On Mon, Sep 21, 2020 at 11:33 PM Noble Paul <noble.paul@gmail.com> wrote:

> We should deprecate that feature and remove restlet dependency altogether
>
> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein <joelsolr@gmail.com>
> wrote:
> >
> > Restlet again!!!!!!!
> >
> >
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
> >
> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <
> epugh@opensourceconnections.com> wrote:
> >>
> >> Do we have a community blessed alternative to restlet already?
> >>
> >> On Sep 20, 2020, at 9:40 AM, Noble Paul <noble.paul@gmail.com> wrote:
> >>
> >> Haha.
> >>
> >> In fact schema APIs don't use restlet. Only the managed resources use it
> >>
> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
> >>>
> >>> If I were talend, I'd immediately start publishing to maven central.
> If I were the developer who built the schema APIs, I would never have used
> restlet to begin with.
> >>>
> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, <uwe@thetaphi.de> wrote:
> >>>>
> >>>> I was thinking the same. Because GitHub does not cache the downloaded
> artifacts like our jenkins servers.
> >>>>
> >>>> It seems to run it in a new VM or container every time, so it
> downloads all artifacts. If I were Talend, I'd also block this.
> >>>>
> >>>> Uwe
> >>>>
> >>>> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
> dawid.weiss@gmail.com>:
> >>>>>
> >>>>> I don't think it's http/https - I believe restlet repository simply
> >>>>> bans github servers because of excessive traffic? These URLs work for
> >>>>> me locally...
> >>>>>
> >>>>> Dawid
> >>>>>
> >>>>> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
> >>>>> LONDON) <cpoerschke@bloomberg.net> wrote:
> >>>>>>
> >>>>>>
> >>>>>> This sounds vaguely familiar. "http works, https does not work"
> and https://issues.apache.org/jira/browse/SOLR-13756 possibly related?
> >>>>>>
> >>>>>> From: dev@lucene.apache.org At: 09/18/20 10:01:29
> >>>>>> To: dev@lucene.apache.org
> >>>>>> Subject: Re: restlet dependencies
> >>>>>>
> >>>>>> I don't think it is, sadly.
> >>>>>> https://repo1.maven.org/maven2/org/restlet
> >>>>>>
> >>>>>> The link you provided (mvnrepository) aggregates from several maven
> >>>>>> repositories.
> >>>>>>
> >>>>>>
> >>>>>> D.
> >>>>>>
> >>>>>> On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
> >>>>>> <ichattopadhyaya@gmail.com> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> Sorry, afk, but I heard (*hearsay*) that restlet is also on maven
> central
> >>>>>>
> >>>>>> these days. Can we confirm and switch to that? Sorry, if that's not
> the case.
> >>>>>>>
> >>>>>>>
> >>>>>>> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <dawid.weiss@gmail.com>
> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Just FYI: can't get PR builds on github to work recently because
> of this:
> >>>>>>>>
> >>>>>>>>> Could not resolve all files for configuration
> >>>>>>
> >>>>>> ':solr:core:compileClasspath'.
> >>>>>>>>
> >>>>>>>> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
> >>>>>>>> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
> >>>>>>>> 351 > Could not get resource
> >>>>>>>>
> >>>>>> '
> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
> >>>>>> tlet.ext.servlet-2.4.3.jar'.
> >>>>>>>>
> >>>>>>>> 352 > Could not GET
> >>>>>>>>
> >>>>>> '
> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
> >>>>>> tlet.ext.servlet-2.4.3.jar'.
> >>>>>>>>
> >>>>>>>> 353 > Connection reset
> >>>>>>>> 354 > Could not download org.restlet-2.4.3.jar
> >>>>>>>> (org.restlet.jee:org.restlet:2.4.3)
> >>>>>>>> 355 > Could not get resource
> >>>>>>>>
> >>>>>> '
> https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
> >>>>>> ar'.
> >>>>>>>>
> >>>>>>>> 356 > Could not GET
> >>>>>>>>
> >>>>>> '
> https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
> >>>>>> 2.4.3.jar'.
> >>>>>>>>
> >>>>>>>> 357 > Connection reset
> >>>>>>>>
> >>>>>>>> D.
> >>>>>>>> ________________________________
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>>>>>
> >>>>>> ________________________________
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>>>
> >>>>>>
> >>>>> ________________________________
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>>
> >>>>
> >>>> --
> >>>> Uwe Schindler
> >>>> Achterdiek 19, 28357 Bremen
> >>>> https://www.thetaphi.de
> >>
> >>
> >> _______________________
> >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467
> | http://www.opensourceconnections.com | My Free/Busy
> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> >> This e-mail and all contents, including attachments, is considered to
> be Company Confidential unless explicitly stated otherwise, regardless of
> whether attachments are marked as such.
> >>
>
>
> --
> -----------------------------------------------------
> Noble Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: restlet dependencies [ In reply to ]
How much harder are the use-cases currently covered by managed
resources, if that module was removed?

For standalone instances, it is nearly as easy to edit the file and
reload the schema. And it will probably be more version-control
friendly than the files currently saved by the module.
What about for SolrCloud?

My feeling is that this module did not catch on, I don't think anybody
ever implemented additional managed resources, though I remember
seeing Jiras. So, unless there are super-special use cases, I am +1 on
deprecating it ASAP for 8.7 and removing it in 9. It will fit with the
overall theme of getting slimmer and more consistent.

Regards,
Alex.
P.s. Also, I think the question on SolrUsers about this had limited
response and mentioned a security issue.


On Wed, 23 Sep 2020 at 10:28, Timothy Potter <thelabdude@gmail.com> wrote:
>
> I agree we should deprecate the managed resources feature, it was the first thing I was asked to build by LW nearly 7 years ago, before I was a committer. Restlet was already in place and I built on top of that, not sure who introduced it originally (nor do I care). Clearly from the vantage point of looking back, JAX-RS and Jersey won the day with REST in Java but that simply wasn't the case back then. What's important is how we move forward vs. bestowing judgement backed by wisdom of hindsight on decisions made many years ago.
>
> In the short term, does Apache have an Artifactory (or similar) where we can host the Restlet dependencies for Github to pull them from? If not, then we can port the code that's using Restlet over to using JAX-RS / Jersey. Personally I'd prefer we remove Managed Resources support from 9 instead of porting the Restlet code but I don't know if 9 is too soon from a deprecation stand point?
>
> Tim
>
>
> On Mon, Sep 21, 2020 at 11:33 PM Noble Paul <noble.paul@gmail.com> wrote:
>>
>> We should deprecate that feature and remove restlet dependency altogether
>>
>> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein <joelsolr@gmail.com> wrote:
>> >
>> > Restlet again!!!!!!!
>> >
>> >
>> >
>> > Joel Bernstein
>> > http://joelsolr.blogspot.com/
>> >
>> >
>> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <epugh@opensourceconnections.com> wrote:
>> >>
>> >> Do we have a community blessed alternative to restlet already?
>> >>
>> >> On Sep 20, 2020, at 9:40 AM, Noble Paul <noble.paul@gmail.com> wrote:
>> >>
>> >> Haha.
>> >>
>> >> In fact schema APIs don't use restlet. Only the managed resources use it
>> >>
>> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <ichattopadhyaya@gmail.com> wrote:
>> >>>
>> >>> If I were talend, I'd immediately start publishing to maven central. If I were the developer who built the schema APIs, I would never have used restlet to begin with.
>> >>>
>> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, <uwe@thetaphi.de> wrote:
>> >>>>
>> >>>> I was thinking the same. Because GitHub does not cache the downloaded artifacts like our jenkins servers.
>> >>>>
>> >>>> It seems to run it in a new VM or container every time, so it downloads all artifacts. If I were Talend, I'd also block this.
>> >>>>
>> >>>> Uwe
>> >>>>
>> >>>> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <dawid.weiss@gmail.com>:
>> >>>>>
>> >>>>> I don't think it's http/https - I believe restlet repository simply
>> >>>>> bans github servers because of excessive traffic? These URLs work for
>> >>>>> me locally...
>> >>>>>
>> >>>>> Dawid
>> >>>>>
>> >>>>> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
>> >>>>> LONDON) <cpoerschke@bloomberg.net> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>> This sounds vaguely familiar. "http works, https does not work" and https://issues.apache.org/jira/browse/SOLR-13756 possibly related?
>> >>>>>>
>> >>>>>> From: dev@lucene.apache.org At: 09/18/20 10:01:29
>> >>>>>> To: dev@lucene.apache.org
>> >>>>>> Subject: Re: restlet dependencies
>> >>>>>>
>> >>>>>> I don't think it is, sadly.
>> >>>>>> https://repo1.maven.org/maven2/org/restlet
>> >>>>>>
>> >>>>>> The link you provided (mvnrepository) aggregates from several maven
>> >>>>>> repositories.
>> >>>>>>
>> >>>>>>
>> >>>>>> D.
>> >>>>>>
>> >>>>>> On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
>> >>>>>> <ichattopadhyaya@gmail.com> wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Sorry, afk, but I heard (*hearsay*) that restlet is also on maven central
>> >>>>>>
>> >>>>>> these days. Can we confirm and switch to that? Sorry, if that's not the case.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <dawid.weiss@gmail.com> wrote:
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Just FYI: can't get PR builds on github to work recently because of this:
>> >>>>>>>>
>> >>>>>>>>> Could not resolve all files for configuration
>> >>>>>>
>> >>>>>> ':solr:core:compileClasspath'.
>> >>>>>>>>
>> >>>>>>>> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>> >>>>>>>> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>> >>>>>>>> 351 > Could not get resource
>> >>>>>>>>
>> >>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>> >>>>>>>>
>> >>>>>>>> 352 > Could not GET
>> >>>>>>>>
>> >>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>> >>>>>>>>
>> >>>>>>>> 353 > Connection reset
>> >>>>>>>> 354 > Could not download org.restlet-2.4.3.jar
>> >>>>>>>> (org.restlet.jee:org.restlet:2.4.3)
>> >>>>>>>> 355 > Could not get resource
>> >>>>>>>>
>> >>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
>> >>>>>> ar'.
>> >>>>>>>>
>> >>>>>>>> 356 > Could not GET
>> >>>>>>>>
>> >>>>>> 'https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
>> >>>>>> 2.4.3.jar'.
>> >>>>>>>>
>> >>>>>>>> 357 > Connection reset
>> >>>>>>>>
>> >>>>>>>> D.
>> >>>>>>>> ________________________________
>> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>>>>>>>
>> >>>>>> ________________________________
>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>>>>>
>> >>>>>>
>> >>>>> ________________________________
>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>>>>
>> >>>>
>> >>>> --
>> >>>> Uwe Schindler
>> >>>> Achterdiek 19, 28357 Bremen
>> >>>> https://www.thetaphi.de
>> >>
>> >>
>> >> _______________________
>> >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> >> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
>> >>
>>
>>
>> --
>> -----------------------------------------------------
>> Noble Paul
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: restlet dependencies [ In reply to ]
We don't need Jersey either. It is already possible for Solr to accept
arbitrarily nested paths for endpoints (using annotations) without using
Restlet or Jersey.

On Wed, 23 Sep, 2020, 8:16 pm Alexandre Rafalovitch, <arafalov@gmail.com>
wrote:

> How much harder are the use-cases currently covered by managed
> resources, if that module was removed?
>
> For standalone instances, it is nearly as easy to edit the file and
> reload the schema. And it will probably be more version-control
> friendly than the files currently saved by the module.
> What about for SolrCloud?
>
> My feeling is that this module did not catch on, I don't think anybody
> ever implemented additional managed resources, though I remember
> seeing Jiras. So, unless there are super-special use cases, I am +1 on
> deprecating it ASAP for 8.7 and removing it in 9. It will fit with the
> overall theme of getting slimmer and more consistent.
>
> Regards,
> Alex.
> P.s. Also, I think the question on SolrUsers about this had limited
> response and mentioned a security issue.
>
>
> On Wed, 23 Sep 2020 at 10:28, Timothy Potter <thelabdude@gmail.com> wrote:
> >
> > I agree we should deprecate the managed resources feature, it was the
> first thing I was asked to build by LW nearly 7 years ago, before I was a
> committer. Restlet was already in place and I built on top of that, not
> sure who introduced it originally (nor do I care). Clearly from the vantage
> point of looking back, JAX-RS and Jersey won the day with REST in Java but
> that simply wasn't the case back then. What's important is how we move
> forward vs. bestowing judgement backed by wisdom of hindsight on decisions
> made many years ago.
> >
> > In the short term, does Apache have an Artifactory (or similar) where we
> can host the Restlet dependencies for Github to pull them from? If not,
> then we can port the code that's using Restlet over to using JAX-RS /
> Jersey. Personally I'd prefer we remove Managed Resources support from 9
> instead of porting the Restlet code but I don't know if 9 is too soon from
> a deprecation stand point?
> >
> > Tim
> >
> >
> > On Mon, Sep 21, 2020 at 11:33 PM Noble Paul <noble.paul@gmail.com>
> wrote:
> >>
> >> We should deprecate that feature and remove restlet dependency
> altogether
> >>
> >> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein <joelsolr@gmail.com>
> wrote:
> >> >
> >> > Restlet again!!!!!!!
> >> >
> >> >
> >> >
> >> > Joel Bernstein
> >> > http://joelsolr.blogspot.com/
> >> >
> >> >
> >> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <
> epugh@opensourceconnections.com> wrote:
> >> >>
> >> >> Do we have a community blessed alternative to restlet already?
> >> >>
> >> >> On Sep 20, 2020, at 9:40 AM, Noble Paul <noble.paul@gmail.com>
> wrote:
> >> >>
> >> >> Haha.
> >> >>
> >> >> In fact schema APIs don't use restlet. Only the managed resources
> use it
> >> >>
> >> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
> >> >>>
> >> >>> If I were talend, I'd immediately start publishing to maven
> central. If I were the developer who built the schema APIs, I would never
> have used restlet to begin with.
> >> >>>
> >> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, <uwe@thetaphi.de>
> wrote:
> >> >>>>
> >> >>>> I was thinking the same. Because GitHub does not cache the
> downloaded artifacts like our jenkins servers.
> >> >>>>
> >> >>>> It seems to run it in a new VM or container every time, so it
> downloads all artifacts. If I were Talend, I'd also block this.
> >> >>>>
> >> >>>> Uwe
> >> >>>>
> >> >>>> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
> dawid.weiss@gmail.com>:
> >> >>>>>
> >> >>>>> I don't think it's http/https - I believe restlet repository
> simply
> >> >>>>> bans github servers because of excessive traffic? These URLs work
> for
> >> >>>>> me locally...
> >> >>>>>
> >> >>>>> Dawid
> >> >>>>>
> >> >>>>> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
> >> >>>>> LONDON) <cpoerschke@bloomberg.net> wrote:
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> This sounds vaguely familiar. "http works, https does not work"
> and https://issues.apache.org/jira/browse/SOLR-13756 possibly related?
> >> >>>>>>
> >> >>>>>> From: dev@lucene.apache.org At: 09/18/20 10:01:29
> >> >>>>>> To: dev@lucene.apache.org
> >> >>>>>> Subject: Re: restlet dependencies
> >> >>>>>>
> >> >>>>>> I don't think it is, sadly.
> >> >>>>>> https://repo1.maven.org/maven2/org/restlet
> >> >>>>>>
> >> >>>>>> The link you provided (mvnrepository) aggregates from several
> maven
> >> >>>>>> repositories.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> D.
> >> >>>>>>
> >> >>>>>> On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
> >> >>>>>> <ichattopadhyaya@gmail.com> wrote:
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> Sorry, afk, but I heard (*hearsay*) that restlet is also on
> maven central
> >> >>>>>>
> >> >>>>>> these days. Can we confirm and switch to that? Sorry, if that's
> not the case.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <
> dawid.weiss@gmail.com> wrote:
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> Just FYI: can't get PR builds on github to work recently
> because of this:
> >> >>>>>>>>
> >> >>>>>>>>> Could not resolve all files for configuration
> >> >>>>>>
> >> >>>>>> ':solr:core:compileClasspath'.
> >> >>>>>>>>
> >> >>>>>>>> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
> >> >>>>>>>> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
> >> >>>>>>>> 351 > Could not get resource
> >> >>>>>>>>
> >> >>>>>> '
> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
> >> >>>>>> tlet.ext.servlet-2.4.3.jar'.
> >> >>>>>>>>
> >> >>>>>>>> 352 > Could not GET
> >> >>>>>>>>
> >> >>>>>> '
> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
> >> >>>>>> tlet.ext.servlet-2.4.3.jar'.
> >> >>>>>>>>
> >> >>>>>>>> 353 > Connection reset
> >> >>>>>>>> 354 > Could not download org.restlet-2.4.3.jar
> >> >>>>>>>> (org.restlet.jee:org.restlet:2.4.3)
> >> >>>>>>>> 355 > Could not get resource
> >> >>>>>>>>
> >> >>>>>> '
> https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
> >> >>>>>> ar'.
> >> >>>>>>>>
> >> >>>>>>>> 356 > Could not GET
> >> >>>>>>>>
> >> >>>>>> '
> https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
> >> >>>>>> 2.4.3.jar'.
> >> >>>>>>>>
> >> >>>>>>>> 357 > Connection reset
> >> >>>>>>>>
> >> >>>>>>>> D.
> >> >>>>>>>> ________________________________
> >> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >> >>>>>>>>
> >> >>>>>> ________________________________
> >> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >> >>>>>>
> >> >>>>>>
> >> >>>>> ________________________________
> >> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >> >>>>>
> >> >>>>
> >> >>>> --
> >> >>>> Uwe Schindler
> >> >>>> Achterdiek 19, 28357 Bremen
> >> >>>> https://www.thetaphi.de
> >> >>
> >> >>
> >> >> _______________________
> >> >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
> 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
> >> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> >> >> This e-mail and all contents, including attachments, is considered
> to be Company Confidential unless explicitly stated otherwise, regardless
> of whether attachments are marked as such.
> >> >>
> >>
> >>
> >> --
> >> -----------------------------------------------------
> >> Noble Paul
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: restlet dependencies [ In reply to ]
Even better! I still favor removing it in 9 but if not, this sounds like a
good approach

On Wed, Sep 23, 2020 at 8:54 AM Ishan Chattopadhyaya <
ichattopadhyaya@gmail.com> wrote:

> We don't need Jersey either. It is already possible for Solr to accept
> arbitrarily nested paths for endpoints (using annotations) without using
> Restlet or Jersey.
>
> On Wed, 23 Sep, 2020, 8:16 pm Alexandre Rafalovitch, <arafalov@gmail.com>
> wrote:
>
>> How much harder are the use-cases currently covered by managed
>> resources, if that module was removed?
>>
>> For standalone instances, it is nearly as easy to edit the file and
>> reload the schema. And it will probably be more version-control
>> friendly than the files currently saved by the module.
>> What about for SolrCloud?
>>
>> My feeling is that this module did not catch on, I don't think anybody
>> ever implemented additional managed resources, though I remember
>> seeing Jiras. So, unless there are super-special use cases, I am +1 on
>> deprecating it ASAP for 8.7 and removing it in 9. It will fit with the
>> overall theme of getting slimmer and more consistent.
>>
>> Regards,
>> Alex.
>> P.s. Also, I think the question on SolrUsers about this had limited
>> response and mentioned a security issue.
>>
>>
>> On Wed, 23 Sep 2020 at 10:28, Timothy Potter <thelabdude@gmail.com>
>> wrote:
>> >
>> > I agree we should deprecate the managed resources feature, it was the
>> first thing I was asked to build by LW nearly 7 years ago, before I was a
>> committer. Restlet was already in place and I built on top of that, not
>> sure who introduced it originally (nor do I care). Clearly from the vantage
>> point of looking back, JAX-RS and Jersey won the day with REST in Java but
>> that simply wasn't the case back then. What's important is how we move
>> forward vs. bestowing judgement backed by wisdom of hindsight on decisions
>> made many years ago.
>> >
>> > In the short term, does Apache have an Artifactory (or similar) where
>> we can host the Restlet dependencies for Github to pull them from? If not,
>> then we can port the code that's using Restlet over to using JAX-RS /
>> Jersey. Personally I'd prefer we remove Managed Resources support from 9
>> instead of porting the Restlet code but I don't know if 9 is too soon from
>> a deprecation stand point?
>> >
>> > Tim
>> >
>> >
>> > On Mon, Sep 21, 2020 at 11:33 PM Noble Paul <noble.paul@gmail.com>
>> wrote:
>> >>
>> >> We should deprecate that feature and remove restlet dependency
>> altogether
>> >>
>> >> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein <joelsolr@gmail.com>
>> wrote:
>> >> >
>> >> > Restlet again!!!!!!!
>> >> >
>> >> >
>> >> >
>> >> > Joel Bernstein
>> >> > http://joelsolr.blogspot.com/
>> >> >
>> >> >
>> >> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <
>> epugh@opensourceconnections.com> wrote:
>> >> >>
>> >> >> Do we have a community blessed alternative to restlet already?
>> >> >>
>> >> >> On Sep 20, 2020, at 9:40 AM, Noble Paul <noble.paul@gmail.com>
>> wrote:
>> >> >>
>> >> >> Haha.
>> >> >>
>> >> >> In fact schema APIs don't use restlet. Only the managed resources
>> use it
>> >> >>
>> >> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> wrote:
>> >> >>>
>> >> >>> If I were talend, I'd immediately start publishing to maven
>> central. If I were the developer who built the schema APIs, I would never
>> have used restlet to begin with.
>> >> >>>
>> >> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, <uwe@thetaphi.de>
>> wrote:
>> >> >>>>
>> >> >>>> I was thinking the same. Because GitHub does not cache the
>> downloaded artifacts like our jenkins servers.
>> >> >>>>
>> >> >>>> It seems to run it in a new VM or container every time, so it
>> downloads all artifacts. If I were Talend, I'd also block this.
>> >> >>>>
>> >> >>>> Uwe
>> >> >>>>
>> >> >>>> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
>> dawid.weiss@gmail.com>:
>> >> >>>>>
>> >> >>>>> I don't think it's http/https - I believe restlet repository
>> simply
>> >> >>>>> bans github servers because of excessive traffic? These URLs
>> work for
>> >> >>>>> me locally...
>> >> >>>>>
>> >> >>>>> Dawid
>> >> >>>>>
>> >> >>>>> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
>> >> >>>>> LONDON) <cpoerschke@bloomberg.net> wrote:
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> This sounds vaguely familiar. "http works, https does not
>> work" and https://issues.apache.org/jira/browse/SOLR-13756 possibly
>> related?
>> >> >>>>>>
>> >> >>>>>> From: dev@lucene.apache.org At: 09/18/20 10:01:29
>> >> >>>>>> To: dev@lucene.apache.org
>> >> >>>>>> Subject: Re: restlet dependencies
>> >> >>>>>>
>> >> >>>>>> I don't think it is, sadly.
>> >> >>>>>> https://repo1.maven.org/maven2/org/restlet
>> >> >>>>>>
>> >> >>>>>> The link you provided (mvnrepository) aggregates from several
>> maven
>> >> >>>>>> repositories.
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> D.
>> >> >>>>>>
>> >> >>>>>> On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
>> >> >>>>>> <ichattopadhyaya@gmail.com> wrote:
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> Sorry, afk, but I heard (*hearsay*) that restlet is also on
>> maven central
>> >> >>>>>>
>> >> >>>>>> these days. Can we confirm and switch to that? Sorry, if that's
>> not the case.
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <
>> dawid.weiss@gmail.com> wrote:
>> >> >>>>>>>>
>> >> >>>>>>>>
>> >> >>>>>>>> Just FYI: can't get PR builds on github to work recently
>> because of this:
>> >> >>>>>>>>
>> >> >>>>>>>>> Could not resolve all files for configuration
>> >> >>>>>>
>> >> >>>>>> ':solr:core:compileClasspath'.
>> >> >>>>>>>>
>> >> >>>>>>>> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>> >> >>>>>>>> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>> >> >>>>>>>> 351 > Could not get resource
>> >> >>>>>>>>
>> >> >>>>>> '
>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>> >> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>> >> >>>>>>>>
>> >> >>>>>>>> 352 > Could not GET
>> >> >>>>>>>>
>> >> >>>>>> '
>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>> >> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>> >> >>>>>>>>
>> >> >>>>>>>> 353 > Connection reset
>> >> >>>>>>>> 354 > Could not download org.restlet-2.4.3.jar
>> >> >>>>>>>> (org.restlet.jee:org.restlet:2.4.3)
>> >> >>>>>>>> 355 > Could not get resource
>> >> >>>>>>>>
>> >> >>>>>> '
>> https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
>> >> >>>>>> ar'.
>> >> >>>>>>>>
>> >> >>>>>>>> 356 > Could not GET
>> >> >>>>>>>>
>> >> >>>>>> '
>> https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
>> >> >>>>>> 2.4.3.jar'.
>> >> >>>>>>>>
>> >> >>>>>>>> 357 > Connection reset
>> >> >>>>>>>>
>> >> >>>>>>>> D.
>> >> >>>>>>>> ________________________________
>> >> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >> >>>>>>>>
>> >> >>>>>> ________________________________
>> >> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>> ________________________________
>> >> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >> >>>>>
>> >> >>>>
>> >> >>>> --
>> >> >>>> Uwe Schindler
>> >> >>>> Achterdiek 19, 28357 Bremen
>> >> >>>> https://www.thetaphi.de
>> >> >>
>> >> >>
>> >> >> _______________________
>> >> >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
>> 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>> >> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> >> >> This e-mail and all contents, including attachments, is considered
>> to be Company Confidential unless explicitly stated otherwise, regardless
>> of whether attachments are marked as such.
>> >> >>
>> >>
>> >>
>> >> --
>> >> -----------------------------------------------------
>> >> Noble Paul
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
Re: restlet dependencies [ In reply to ]
+1 to deprecate managed resources in lieu of easier to maintain (and more
flexible) file based GET/PUT into the configset.

> I don't know if 9 is too soon from a deprecation stand point

IMO it's never too soon as long as there is a deprecated release. Users
take their time upgrading to major versions.

> How much harder are the use-cases currently covered by managed resources,
if that module was removed?

I believe in practice, users synchronize one-way from their DB to Solr if
they have dynamic resources like this. This is true where I work.
Otherwise, they would probably be using Solr as the source of truth, which
doesn't seem architecturally-sound for most apps IMO. Those users
(hopefully few) would have to spend some time re-engineering the approach.
Given one-way sync, the transition here is pretty easy: serialize the
client-managed data to the right Solr format (stopwords vs synonyms vs ...)
and then a file upload to Solr/ZK and then telling Solr which collections
to "reload".

Hmmm; seems the configSet API doesn't have an API to update a single file!
I wonder if uploading a configSet to the same name effectively overwrites
newly updated files but does not delete the existing files?

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Wed, Sep 23, 2020 at 10:28 AM Timothy Potter <thelabdude@gmail.com>
wrote:

> I agree we should deprecate the managed resources feature, it was the
> first thing I was asked to build by LW nearly 7 years ago, before I was a
> committer. Restlet was already in place and I built on top of that, not
> sure who introduced it originally (nor do I care). Clearly from the vantage
> point of looking back, JAX-RS and Jersey won the day with REST in Java but
> that simply wasn't the case back then. What's important is how we move
> forward vs. bestowing judgement backed by wisdom of hindsight on decisions
> made many years ago.
>
> In the short term, does Apache have an Artifactory (or similar) where we
> can host the Restlet dependencies for Github to pull them from? If not,
> then we can port the code that's using Restlet over to using JAX-RS /
> Jersey. Personally I'd prefer we remove Managed Resources support from 9
> instead of porting the Restlet code but I don't know if 9 is too soon from
> a deprecation stand point?
>
> Tim
>
>
> On Mon, Sep 21, 2020 at 11:33 PM Noble Paul <noble.paul@gmail.com> wrote:
>
>> We should deprecate that feature and remove restlet dependency altogether
>>
>> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein <joelsolr@gmail.com>
>> wrote:
>> >
>> > Restlet again!!!!!!!
>> >
>> >
>> >
>> > Joel Bernstein
>> > http://joelsolr.blogspot.com/
>> >
>> >
>> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <
>> epugh@opensourceconnections.com> wrote:
>> >>
>> >> Do we have a community blessed alternative to restlet already?
>> >>
>> >> On Sep 20, 2020, at 9:40 AM, Noble Paul <noble.paul@gmail.com> wrote:
>> >>
>> >> Haha.
>> >>
>> >> In fact schema APIs don't use restlet. Only the managed resources use
>> it
>> >>
>> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> wrote:
>> >>>
>> >>> If I were talend, I'd immediately start publishing to maven central.
>> If I were the developer who built the schema APIs, I would never have used
>> restlet to begin with.
>> >>>
>> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, <uwe@thetaphi.de> wrote:
>> >>>>
>> >>>> I was thinking the same. Because GitHub does not cache the
>> downloaded artifacts like our jenkins servers.
>> >>>>
>> >>>> It seems to run it in a new VM or container every time, so it
>> downloads all artifacts. If I were Talend, I'd also block this.
>> >>>>
>> >>>> Uwe
>> >>>>
>> >>>> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
>> dawid.weiss@gmail.com>:
>> >>>>>
>> >>>>> I don't think it's http/https - I believe restlet repository simply
>> >>>>> bans github servers because of excessive traffic? These URLs work
>> for
>> >>>>> me locally...
>> >>>>>
>> >>>>> Dawid
>> >>>>>
>> >>>>> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
>> >>>>> LONDON) <cpoerschke@bloomberg.net> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>> This sounds vaguely familiar. "http works, https does not work"
>> and https://issues.apache.org/jira/browse/SOLR-13756 possibly related?
>> >>>>>>
>> >>>>>> From: dev@lucene.apache.org At: 09/18/20 10:01:29
>> >>>>>> To: dev@lucene.apache.org
>> >>>>>> Subject: Re: restlet dependencies
>> >>>>>>
>> >>>>>> I don't think it is, sadly.
>> >>>>>> https://repo1.maven.org/maven2/org/restlet
>> >>>>>>
>> >>>>>> The link you provided (mvnrepository) aggregates from several
>> maven
>> >>>>>> repositories.
>> >>>>>>
>> >>>>>>
>> >>>>>> D.
>> >>>>>>
>> >>>>>> On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
>> >>>>>> <ichattopadhyaya@gmail.com> wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Sorry, afk, but I heard (*hearsay*) that restlet is also on
>> maven central
>> >>>>>>
>> >>>>>> these days. Can we confirm and switch to that? Sorry, if that's
>> not the case.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <
>> dawid.weiss@gmail.com> wrote:
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Just FYI: can't get PR builds on github to work recently
>> because of this:
>> >>>>>>>>
>> >>>>>>>>> Could not resolve all files for configuration
>> >>>>>>
>> >>>>>> ':solr:core:compileClasspath'.
>> >>>>>>>>
>> >>>>>>>> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>> >>>>>>>> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>> >>>>>>>> 351 > Could not get resource
>> >>>>>>>>
>> >>>>>> '
>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>> >>>>>>>>
>> >>>>>>>> 352 > Could not GET
>> >>>>>>>>
>> >>>>>> '
>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>> >>>>>>>>
>> >>>>>>>> 353 > Connection reset
>> >>>>>>>> 354 > Could not download org.restlet-2.4.3.jar
>> >>>>>>>> (org.restlet.jee:org.restlet:2.4.3)
>> >>>>>>>> 355 > Could not get resource
>> >>>>>>>>
>> >>>>>> '
>> https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
>> >>>>>> ar'.
>> >>>>>>>>
>> >>>>>>>> 356 > Could not GET
>> >>>>>>>>
>> >>>>>> '
>> https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
>> >>>>>> 2.4.3.jar'.
>> >>>>>>>>
>> >>>>>>>> 357 > Connection reset
>> >>>>>>>>
>> >>>>>>>> D.
>> >>>>>>>> ________________________________
>> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>>>>>>>
>> >>>>>> ________________________________
>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>>>>>
>> >>>>>>
>> >>>>> ________________________________
>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>>>>
>> >>>>
>> >>>> --
>> >>>> Uwe Schindler
>> >>>> Achterdiek 19, 28357 Bremen
>> >>>> https://www.thetaphi.de
>> >>
>> >>
>> >> _______________________
>> >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467
>> | http://www.opensourceconnections.com | My Free/Busy
>> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> >> This e-mail and all contents, including attachments, is considered to
>> be Company Confidential unless explicitly stated otherwise, regardless of
>> whether attachments are marked as such.
>> >>
>>
>>
>> --
>> -----------------------------------------------------
>> Noble Paul
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
Re: restlet dependencies [ In reply to ]
> Hmmm; seems the configSet API doesn't have an API to update a single
file! I wonder if uploading a configSet to the same name effectively
overwrites newly updated files but does not delete the existing files?
I've been working on this recently. As of 8.7, the UPLOAD command supports
overwriting (before, an UPLOAD on an existing configset name would fail
with BAD_REQUEST) and you can choose to cleanup or not the extra files with
the "cleanup" parameter.
You could upload a single file if you say overwrite=true&cleanup=false, but
it would still need to be in a zip file (and needs to be located in the
right path of the zip, for example, a synonyms file may be in
lang/synonyms_foo.txt or something)

On Wed, Sep 23, 2020 at 8:10 PM David Smiley <dsmiley@apache.org> wrote:

> +1 to deprecate managed resources in lieu of easier to maintain (and more
> flexible) file based GET/PUT into the configset.
>
> > I don't know if 9 is too soon from a deprecation stand point
>
> IMO it's never too soon as long as there is a deprecated release. Users
> take their time upgrading to major versions.
>
> > How much harder are the use-cases currently covered by managed
> resources, if that module was removed?
>
> I believe in practice, users synchronize one-way from their DB to Solr if
> they have dynamic resources like this. This is true where I work.
> Otherwise, they would probably be using Solr as the source of truth, which
> doesn't seem architecturally-sound for most apps IMO. Those users
> (hopefully few) would have to spend some time re-engineering the approach.
> Given one-way sync, the transition here is pretty easy: serialize the
> client-managed data to the right Solr format (stopwords vs synonyms vs ...)
> and then a file upload to Solr/ZK and then telling Solr which collections
> to "reload".
>
> Hmmm; seems the configSet API doesn't have an API to update a single
> file! I wonder if uploading a configSet to the same name effectively
> overwrites newly updated files but does not delete the existing files?
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Sep 23, 2020 at 10:28 AM Timothy Potter <thelabdude@gmail.com>
> wrote:
>
>> I agree we should deprecate the managed resources feature, it was the
>> first thing I was asked to build by LW nearly 7 years ago, before I was a
>> committer. Restlet was already in place and I built on top of that, not
>> sure who introduced it originally (nor do I care). Clearly from the vantage
>> point of looking back, JAX-RS and Jersey won the day with REST in Java but
>> that simply wasn't the case back then. What's important is how we move
>> forward vs. bestowing judgement backed by wisdom of hindsight on decisions
>> made many years ago.
>>
>> In the short term, does Apache have an Artifactory (or similar) where we
>> can host the Restlet dependencies for Github to pull them from? If not,
>> then we can port the code that's using Restlet over to using JAX-RS /
>> Jersey. Personally I'd prefer we remove Managed Resources support from 9
>> instead of porting the Restlet code but I don't know if 9 is too soon from
>> a deprecation stand point?
>>
>> Tim
>>
>>
>> On Mon, Sep 21, 2020 at 11:33 PM Noble Paul <noble.paul@gmail.com> wrote:
>>
>>> We should deprecate that feature and remove restlet dependency altogether
>>>
>>> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein <joelsolr@gmail.com>
>>> wrote:
>>> >
>>> > Restlet again!!!!!!!
>>> >
>>> >
>>> >
>>> > Joel Bernstein
>>> > http://joelsolr.blogspot.com/
>>> >
>>> >
>>> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <
>>> epugh@opensourceconnections.com> wrote:
>>> >>
>>> >> Do we have a community blessed alternative to restlet already?
>>> >>
>>> >> On Sep 20, 2020, at 9:40 AM, Noble Paul <noble.paul@gmail.com> wrote:
>>> >>
>>> >> Haha.
>>> >>
>>> >> In fact schema APIs don't use restlet. Only the managed resources use
>>> it
>>> >>
>>> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
>>> ichattopadhyaya@gmail.com> wrote:
>>> >>>
>>> >>> If I were talend, I'd immediately start publishing to maven central.
>>> If I were the developer who built the schema APIs, I would never have used
>>> restlet to begin with.
>>> >>>
>>> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, <uwe@thetaphi.de>
>>> wrote:
>>> >>>>
>>> >>>> I was thinking the same. Because GitHub does not cache the
>>> downloaded artifacts like our jenkins servers.
>>> >>>>
>>> >>>> It seems to run it in a new VM or container every time, so it
>>> downloads all artifacts. If I were Talend, I'd also block this.
>>> >>>>
>>> >>>> Uwe
>>> >>>>
>>> >>>> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
>>> dawid.weiss@gmail.com>:
>>> >>>>>
>>> >>>>> I don't think it's http/https - I believe restlet repository simply
>>> >>>>> bans github servers because of excessive traffic? These URLs work
>>> for
>>> >>>>> me locally...
>>> >>>>>
>>> >>>>> Dawid
>>> >>>>>
>>> >>>>> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
>>> >>>>> LONDON) <cpoerschke@bloomberg.net> wrote:
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> This sounds vaguely familiar. "http works, https does not work"
>>> and https://issues.apache.org/jira/browse/SOLR-13756 possibly related?
>>> >>>>>>
>>> >>>>>> From: dev@lucene.apache.org At: 09/18/20 10:01:29
>>> >>>>>> To: dev@lucene.apache.org
>>> >>>>>> Subject: Re: restlet dependencies
>>> >>>>>>
>>> >>>>>> I don't think it is, sadly.
>>> >>>>>> https://repo1.maven.org/maven2/org/restlet
>>> >>>>>>
>>> >>>>>> The link you provided (mvnrepository) aggregates from several
>>> maven
>>> >>>>>> repositories.
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> D.
>>> >>>>>>
>>> >>>>>> On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
>>> >>>>>> <ichattopadhyaya@gmail.com> wrote:
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> Sorry, afk, but I heard (*hearsay*) that restlet is also on
>>> maven central
>>> >>>>>>
>>> >>>>>> these days. Can we confirm and switch to that? Sorry, if that's
>>> not the case.
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <
>>> dawid.weiss@gmail.com> wrote:
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> Just FYI: can't get PR builds on github to work recently
>>> because of this:
>>> >>>>>>>>
>>> >>>>>>>>> Could not resolve all files for configuration
>>> >>>>>>
>>> >>>>>> ':solr:core:compileClasspath'.
>>> >>>>>>>>
>>> >>>>>>>> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>>> >>>>>>>> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>>> >>>>>>>> 351 > Could not get resource
>>> >>>>>>>>
>>> >>>>>> '
>>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>>> >>>>>>>>
>>> >>>>>>>> 352 > Could not GET
>>> >>>>>>>>
>>> >>>>>> '
>>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>>> >>>>>>>>
>>> >>>>>>>> 353 > Connection reset
>>> >>>>>>>> 354 > Could not download org.restlet-2.4.3.jar
>>> >>>>>>>> (org.restlet.jee:org.restlet:2.4.3)
>>> >>>>>>>> 355 > Could not get resource
>>> >>>>>>>>
>>> >>>>>> '
>>> https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
>>> >>>>>> ar'.
>>> >>>>>>>>
>>> >>>>>>>> 356 > Could not GET
>>> >>>>>>>>
>>> >>>>>> '
>>> https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
>>> >>>>>> 2.4.3.jar'.
>>> >>>>>>>>
>>> >>>>>>>> 357 > Connection reset
>>> >>>>>>>>
>>> >>>>>>>> D.
>>> >>>>>>>> ________________________________
>>> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>>>>>>>
>>> >>>>>> ________________________________
>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>>>>>
>>> >>>>>>
>>> >>>>> ________________________________
>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>>>>
>>> >>>>
>>> >>>> --
>>> >>>> Uwe Schindler
>>> >>>> Achterdiek 19, 28357 Bremen
>>> >>>> https://www.thetaphi.de
>>> >>
>>> >>
>>> >> _______________________
>>> >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
>>> 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>>> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>> >> This e-mail and all contents, including attachments, is considered to
>>> be Company Confidential unless explicitly stated otherwise, regardless of
>>> whether attachments are marked as such.
>>> >>
>>>
>>>
>>> --
>>> -----------------------------------------------------
>>> Noble Paul
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
Re: restlet dependencies [ In reply to ]
Thank you for considering doing something with this, guys. Not
pointing fingers at anyone but those restlet dependencies are causing
notorious problems, in many places (and the invalid empty manifest
entry is the most annoying of all...).

Dawid

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: restlet dependencies [ In reply to ]
It would be great if we had a simple API for updating a file in a configset that didn’t assume you were just uploading a zip file.

As an example use case, if you use the Querqy library, you need to deploy a “rules.txt” file, which in olden days just went on the filesystem and you would click reload on a core. In the SolrCloud world, we do this awkward “Let me stick the file in Zookeeper directly, avoiding Solr, and then do a collection RELOAD” to push out the file everywhere. [1] It works! But it’s just awkward.

It’s great to know that I’ll be able to change out this awkward process using these magic parameters to configSet. Even nicer would be to just wrap the overwrite=true&cleanup=false and the Zip requirement into something that sets those.


[1] https://github.com/querqy/chorus/blob/master/smui/conf/smui2solrcloud.sh#L37

> On Sep 23, 2020, at 11:57 PM, Tomás Fernández Löbbe <tomasflobbe@gmail.com> wrote:
>
> > Hmmm; seems the configSet API doesn't have an API to update a single file! I wonder if uploading a configSet to the same name effectively overwrites newly updated files but does not delete the existing files?
> I've been working on this recently. As of 8.7, the UPLOAD command supports overwriting (before, an UPLOAD on an existing configset name would fail with BAD_REQUEST) and you can choose to cleanup or not the extra files with the "cleanup" parameter.
> You could upload a single file if you say overwrite=true&cleanup=false, but it would still need to be in a zip file (and needs to be located in the right path of the zip, for example, a synonyms file may be in lang/synonyms_foo.txt or something)
>
> On Wed, Sep 23, 2020 at 8:10 PM David Smiley <dsmiley@apache.org <mailto:dsmiley@apache.org>> wrote:
> +1 to deprecate managed resources in lieu of easier to maintain (and more flexible) file based GET/PUT into the configset.
>
> > I don't know if 9 is too soon from a deprecation stand point
>
> IMO it's never too soon as long as there is a deprecated release. Users take their time upgrading to major versions.
>
> > How much harder are the use-cases currently covered by managed resources, if that module was removed?
>
> I believe in practice, users synchronize one-way from their DB to Solr if they have dynamic resources like this. This is true where I work. Otherwise, they would probably be using Solr as the source of truth, which doesn't seem architecturally-sound for most apps IMO. Those users (hopefully few) would have to spend some time re-engineering the approach. Given one-way sync, the transition here is pretty easy: serialize the client-managed data to the right Solr format (stopwords vs synonyms vs ...) and then a file upload to Solr/ZK and then telling Solr which collections to "reload".
>
> Hmmm; seems the configSet API doesn't have an API to update a single file! I wonder if uploading a configSet to the same name effectively overwrites newly updated files but does not delete the existing files?
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley <http://www.linkedin.com/in/davidwsmiley>
>
> On Wed, Sep 23, 2020 at 10:28 AM Timothy Potter <thelabdude@gmail.com <mailto:thelabdude@gmail.com>> wrote:
> I agree we should deprecate the managed resources feature, it was the first thing I was asked to build by LW nearly 7 years ago, before I was a committer. Restlet was already in place and I built on top of that, not sure who introduced it originally (nor do I care). Clearly from the vantage point of looking back, JAX-RS and Jersey won the day with REST in Java but that simply wasn't the case back then. What's important is how we move forward vs. bestowing judgement backed by wisdom of hindsight on decisions made many years ago.
>
> In the short term, does Apache have an Artifactory (or similar) where we can host the Restlet dependencies for Github to pull them from? If not, then we can port the code that's using Restlet over to using JAX-RS / Jersey. Personally I'd prefer we remove Managed Resources support from 9 instead of porting the Restlet code but I don't know if 9 is too soon from a deprecation stand point?
>
> Tim
>
>
> On Mon, Sep 21, 2020 at 11:33 PM Noble Paul <noble.paul@gmail.com <mailto:noble.paul@gmail.com>> wrote:
> We should deprecate that feature and remove restlet dependency altogether
>
> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein <joelsolr@gmail.com <mailto:joelsolr@gmail.com>> wrote:
> >
> > Restlet again!!!!!!!
> >
> >
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/ <http://joelsolr.blogspot.com/>
> >
> >
> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <epugh@opensourceconnections.com <mailto:epugh@opensourceconnections.com>> wrote:
> >>
> >> Do we have a community blessed alternative to restlet already?
> >>
> >> On Sep 20, 2020, at 9:40 AM, Noble Paul <noble.paul@gmail.com <mailto:noble.paul@gmail.com>> wrote:
> >>
> >> Haha.
> >>
> >> In fact schema APIs don't use restlet. Only the managed resources use it
> >>
> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com>> wrote:
> >>>
> >>> If I were talend, I'd immediately start publishing to maven central. If I were the developer who built the schema APIs, I would never have used restlet to begin with.
> >>>
> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, <uwe@thetaphi.de <mailto:uwe@thetaphi.de>> wrote:
> >>>>
> >>>> I was thinking the same. Because GitHub does not cache the downloaded artifacts like our jenkins servers.
> >>>>
> >>>> It seems to run it in a new VM or container every time, so it downloads all artifacts. If I were Talend, I'd also block this.
> >>>>
> >>>> Uwe
> >>>>
> >>>> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <dawid.weiss@gmail.com <mailto:dawid.weiss@gmail.com>>:
> >>>>>
> >>>>> I don't think it's http/https - I believe restlet repository simply
> >>>>> bans github servers because of excessive traffic? These URLs work for
> >>>>> me locally...
> >>>>>
> >>>>> Dawid
> >>>>>
> >>>>> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
> >>>>> LONDON) <cpoerschke@bloomberg.net <mailto:cpoerschke@bloomberg.net>> wrote:
> >>>>>>
> >>>>>>
> >>>>>> This sounds vaguely familiar. "http works, https does not work" and https://issues.apache.org/jira/browse/SOLR-13756 <https://issues.apache.org/jira/browse/SOLR-13756> possibly related?
> >>>>>>
> >>>>>> From: dev@lucene.apache.org <mailto:dev@lucene.apache.org> At: 09/18/20 10:01:29
> >>>>>> To: dev@lucene.apache.org <mailto:dev@lucene.apache.org>
> >>>>>> Subject: Re: restlet dependencies
> >>>>>>
> >>>>>> I don't think it is, sadly.
> >>>>>> https://repo1.maven.org/maven2/org/restlet <https://repo1.maven.org/maven2/org/restlet>
> >>>>>>
> >>>>>> The link you provided (mvnrepository) aggregates from several maven
> >>>>>> repositories.
> >>>>>>
> >>>>>>
> >>>>>> D.
> >>>>>>
> >>>>>> On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
> >>>>>> <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com>> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> Sorry, afk, but I heard (*hearsay*) that restlet is also on maven central
> >>>>>>
> >>>>>> these days. Can we confirm and switch to that? Sorry, if that's not the case.
> >>>>>>>
> >>>>>>>
> >>>>>>> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <dawid.weiss@gmail.com <mailto:dawid.weiss@gmail.com>> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Just FYI: can't get PR builds on github to work recently because of this:
> >>>>>>>>
> >>>>>>>>> Could not resolve all files for configuration
> >>>>>>
> >>>>>> ':solr:core:compileClasspath'.
> >>>>>>>>
> >>>>>>>> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
> >>>>>>>> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
> >>>>>>>> 351 > Could not get resource
> >>>>>>>>
> >>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res <https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res>
> >>>>>> tlet.ext.servlet-2.4.3.jar'.
> >>>>>>>>
> >>>>>>>> 352 > Could not GET
> >>>>>>>>
> >>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res <https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res>
> >>>>>> tlet.ext.servlet-2.4.3.jar'.
> >>>>>>>>
> >>>>>>>> 353 > Connection reset
> >>>>>>>> 354 > Could not download org.restlet-2.4.3.jar
> >>>>>>>> (org.restlet.jee:org.restlet:2.4.3)
> >>>>>>>> 355 > Could not get resource
> >>>>>>>>
> >>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j <https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j>
> >>>>>> ar'.
> >>>>>>>>
> >>>>>>>> 356 > Could not GET
> >>>>>>>>
> >>>>>> 'https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet- <https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet->
> >>>>>> 2.4.3.jar'.
> >>>>>>>>
> >>>>>>>> 357 > Connection reset
> >>>>>>>>
> >>>>>>>> D.
> >>>>>>>> ________________________________
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
> >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
> >>>>>>>>
> >>>>>> ________________________________
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
> >>>>>>
> >>>>>>
> >>>>> ________________________________
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
> >>>>>
> >>>>
> >>>> --
> >>>> Uwe Schindler
> >>>> Achterdiek 19, 28357 Bremen
> >>>> https://www.thetaphi.de <https://www.thetaphi.de/>
> >>
> >>
> >> _______________________
> >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy
> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> >> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
> >>
>
>
> --
> -----------------------------------------------------
> Noble Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
>

_______________________
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal>
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
Re: restlet dependencies [ In reply to ]
I won't step in the way of a single file update. I haven't needed it so far
though. I usually have the configsets in a Git repo (all the configset
together) and I have a simple bash script that essentialy what's described
in the docs[1]: Generate the zip on the fly and upload (optionally set the
auth too). This can become a problem with big zips, but then again,
ZooKeeper limits the size of the configs, so far it hasn't been an issue
for me.


[1]
https://lucene.apache.org/solr/guide/8_6/configsets-api.html#configsets-upload

On Thu, Sep 24, 2020 at 7:13 AM Eric Pugh <epugh@opensourceconnections.com>
wrote:

> It would be great if we had a simple API for updating a file in a
> configset that didn’t assume you were just uploading a zip file.
>
> As an example use case, if you use the Querqy library, you need to deploy
> a “rules.txt” file, which in olden days just went on the filesystem and you
> would click reload on a core. In the SolrCloud world, we do this awkward
> “Let me stick the file in Zookeeper directly, avoiding Solr, and then do a
> collection RELOAD” to push out the file everywhere. [1] It works! But
> it’s just awkward.
>
> It’s great to know that I’ll be able to change out this awkward process
> using these magic parameters to configSet. Even nicer would be to just
> wrap the overwrite=true&cleanup=false and the Zip requirement into
> something that sets those.
>
>
> [1]
> https://github.com/querqy/chorus/blob/master/smui/conf/smui2solrcloud.sh#L37
>
> On Sep 23, 2020, at 11:57 PM, Tomás Fernández Löbbe <tomasflobbe@gmail.com>
> wrote:
>
> > Hmmm; seems the configSet API doesn't have an API to update a single
> file! I wonder if uploading a configSet to the same name effectively
> overwrites newly updated files but does not delete the existing files?
> I've been working on this recently. As of 8.7, the UPLOAD command supports
> overwriting (before, an UPLOAD on an existing configset name would fail
> with BAD_REQUEST) and you can choose to cleanup or not the extra files with
> the "cleanup" parameter.
> You could upload a single file if you say overwrite=true&cleanup=false,
> but it would still need to be in a zip file (and needs to be located in the
> right path of the zip, for example, a synonyms file may be in
> lang/synonyms_foo.txt or something)
>
> On Wed, Sep 23, 2020 at 8:10 PM David Smiley <dsmiley@apache.org> wrote:
>
>> +1 to deprecate managed resources in lieu of easier to maintain (and more
>> flexible) file based GET/PUT into the configset.
>>
>> > I don't know if 9 is too soon from a deprecation stand point
>>
>> IMO it's never too soon as long as there is a deprecated release. Users
>> take their time upgrading to major versions.
>>
>> > How much harder are the use-cases currently covered by managed
>> resources, if that module was removed?
>>
>> I believe in practice, users synchronize one-way from their DB to Solr if
>> they have dynamic resources like this. This is true where I work.
>> Otherwise, they would probably be using Solr as the source of truth, which
>> doesn't seem architecturally-sound for most apps IMO. Those users
>> (hopefully few) would have to spend some time re-engineering the approach.
>> Given one-way sync, the transition here is pretty easy: serialize the
>> client-managed data to the right Solr format (stopwords vs synonyms vs ...)
>> and then a file upload to Solr/ZK and then telling Solr which collections
>> to "reload".
>>
>> Hmmm; seems the configSet API doesn't have an API to update a single
>> file! I wonder if uploading a configSet to the same name effectively
>> overwrites newly updated files but does not delete the existing files?
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Wed, Sep 23, 2020 at 10:28 AM Timothy Potter <thelabdude@gmail.com>
>> wrote:
>>
>>> I agree we should deprecate the managed resources feature, it was the
>>> first thing I was asked to build by LW nearly 7 years ago, before I was a
>>> committer. Restlet was already in place and I built on top of that, not
>>> sure who introduced it originally (nor do I care). Clearly from the vantage
>>> point of looking back, JAX-RS and Jersey won the day with REST in Java but
>>> that simply wasn't the case back then. What's important is how we move
>>> forward vs. bestowing judgement backed by wisdom of hindsight on decisions
>>> made many years ago.
>>>
>>> In the short term, does Apache have an Artifactory (or similar) where we
>>> can host the Restlet dependencies for Github to pull them from? If not,
>>> then we can port the code that's using Restlet over to using JAX-RS /
>>> Jersey. Personally I'd prefer we remove Managed Resources support from 9
>>> instead of porting the Restlet code but I don't know if 9 is too soon from
>>> a deprecation stand point?
>>>
>>> Tim
>>>
>>>
>>> On Mon, Sep 21, 2020 at 11:33 PM Noble Paul <noble.paul@gmail.com>
>>> wrote:
>>>
>>>> We should deprecate that feature and remove restlet dependency
>>>> altogether
>>>>
>>>> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein <joelsolr@gmail.com>
>>>> wrote:
>>>> >
>>>> > Restlet again!!!!!!!
>>>> >
>>>> >
>>>> >
>>>> > Joel Bernstein
>>>> > http://joelsolr.blogspot.com/
>>>> >
>>>> >
>>>> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <
>>>> epugh@opensourceconnections.com> wrote:
>>>> >>
>>>> >> Do we have a community blessed alternative to restlet already?
>>>> >>
>>>> >> On Sep 20, 2020, at 9:40 AM, Noble Paul <noble.paul@gmail.com>
>>>> wrote:
>>>> >>
>>>> >> Haha.
>>>> >>
>>>> >> In fact schema APIs don't use restlet. Only the managed resources
>>>> use it
>>>> >>
>>>> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
>>>> ichattopadhyaya@gmail.com> wrote:
>>>> >>>
>>>> >>> If I were talend, I'd immediately start publishing to maven
>>>> central. If I were the developer who built the schema APIs, I would never
>>>> have used restlet to begin with.
>>>> >>>
>>>> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, <uwe@thetaphi.de>
>>>> wrote:
>>>> >>>>
>>>> >>>> I was thinking the same. Because GitHub does not cache the
>>>> downloaded artifacts like our jenkins servers.
>>>> >>>>
>>>> >>>> It seems to run it in a new VM or container every time, so it
>>>> downloads all artifacts. If I were Talend, I'd also block this.
>>>> >>>>
>>>> >>>> Uwe
>>>> >>>>
>>>> >>>> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
>>>> dawid.weiss@gmail.com>:
>>>> >>>>>
>>>> >>>>> I don't think it's http/https - I believe restlet repository
>>>> simply
>>>> >>>>> bans github servers because of excessive traffic? These URLs work
>>>> for
>>>> >>>>> me locally...
>>>> >>>>>
>>>> >>>>> Dawid
>>>> >>>>>
>>>> >>>>> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
>>>> >>>>> LONDON) <cpoerschke@bloomberg.net> wrote:
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> This sounds vaguely familiar. "http works, https does not work"
>>>> and https://issues.apache.org/jira/browse/SOLR-13756 possibly related?
>>>> >>>>>>
>>>> >>>>>> From: dev@lucene.apache.org At: 09/18/20 10:01:29
>>>> >>>>>> To: dev@lucene.apache.org
>>>> >>>>>> Subject: Re: restlet dependencies
>>>> >>>>>>
>>>> >>>>>> I don't think it is, sadly.
>>>> >>>>>> https://repo1.maven.org/maven2/org/restlet
>>>> >>>>>>
>>>> >>>>>> The link you provided (mvnrepository) aggregates from several
>>>> maven
>>>> >>>>>> repositories.
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> D.
>>>> >>>>>>
>>>> >>>>>> On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
>>>> >>>>>> <ichattopadhyaya@gmail.com> wrote:
>>>> >>>>>>>
>>>> >>>>>>>
>>>> >>>>>>> Sorry, afk, but I heard (*hearsay*) that restlet is also on
>>>> maven central
>>>> >>>>>>
>>>> >>>>>> these days. Can we confirm and switch to that? Sorry, if that's
>>>> not the case.
>>>> >>>>>>>
>>>> >>>>>>>
>>>> >>>>>>> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <
>>>> dawid.weiss@gmail.com> wrote:
>>>> >>>>>>>>
>>>> >>>>>>>>
>>>> >>>>>>>> Just FYI: can't get PR builds on github to work recently
>>>> because of this:
>>>> >>>>>>>>
>>>> >>>>>>>>> Could not resolve all files for configuration
>>>> >>>>>>
>>>> >>>>>> ':solr:core:compileClasspath'.
>>>> >>>>>>>>
>>>> >>>>>>>> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>>>> >>>>>>>> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>>>> >>>>>>>> 351 > Could not get resource
>>>> >>>>>>>>
>>>> >>>>>> '
>>>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>>>> >>>>>>>>
>>>> >>>>>>>> 352 > Could not GET
>>>> >>>>>>>>
>>>> >>>>>> '
>>>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>>>> >>>>>>>>
>>>> >>>>>>>> 353 > Connection reset
>>>> >>>>>>>> 354 > Could not download org.restlet-2.4.3.jar
>>>> >>>>>>>> (org.restlet.jee:org.restlet:2.4.3)
>>>> >>>>>>>> 355 > Could not get resource
>>>> >>>>>>>>
>>>> >>>>>> '
>>>> https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
>>>> >>>>>> ar'.
>>>> >>>>>>>>
>>>> >>>>>>>> 356 > Could not GET
>>>> >>>>>>>>
>>>> >>>>>> '
>>>> https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
>>>> >>>>>> 2.4.3.jar'.
>>>> >>>>>>>>
>>>> >>>>>>>> 357 > Connection reset
>>>> >>>>>>>>
>>>> >>>>>>>> D.
>>>> >>>>>>>> ________________________________
>>>> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>> >>>>>>>>
>>>> >>>>>> ________________________________
>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>> ________________________________
>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>> >>>>>
>>>> >>>>
>>>> >>>> --
>>>> >>>> Uwe Schindler
>>>> >>>> Achterdiek 19, 28357 Bremen
>>>> >>>> https://www.thetaphi.de
>>>> >>
>>>> >>
>>>> >> _______________________
>>>> >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
>>>> 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>>>> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>>> >> This e-mail and all contents, including attachments, is considered
>>>> to be Company Confidential unless explicitly stated otherwise, regardless
>>>> of whether attachments are marked as such.
>>>> >>
>>>>
>>>>
>>>> --
>>>> -----------------------------------------------------
>>>> Noble Paul
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>>
> _______________________
> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
> | http://www.opensourceconnections.com | My Free/Busy
> <http://tinyurl.com/eric-cal>
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
> This e-mail and all contents, including attachments, is considered to be
> Company Confidential unless explicitly stated otherwise, regardless
> of whether attachments are marked as such.
>
>
Re: restlet dependencies [ In reply to ]
Single file update capability is a security nightmare. Even if it can be
done, it should be supported only once authc/authz have been enabled.

On Thu, 24 Sep, 2020, 10:16 pm Tomás Fernández Löbbe, <tomasflobbe@gmail.com>
wrote:

> I won't step in the way of a single file update. I haven't needed it so
> far though. I usually have the configsets in a Git repo (all the configset
> together) and I have a simple bash script that essentialy what's described
> in the docs[1]: Generate the zip on the fly and upload (optionally set the
> auth too). This can become a problem with big zips, but then again,
> ZooKeeper limits the size of the configs, so far it hasn't been an issue
> for me.
>
>
> [1]
> https://lucene.apache.org/solr/guide/8_6/configsets-api.html#configsets-upload
>
> On Thu, Sep 24, 2020 at 7:13 AM Eric Pugh <epugh@opensourceconnections.com>
> wrote:
>
>> It would be great if we had a simple API for updating a file in a
>> configset that didn’t assume you were just uploading a zip file.
>>
>> As an example use case, if you use the Querqy library, you need to deploy
>> a “rules.txt” file, which in olden days just went on the filesystem and you
>> would click reload on a core. In the SolrCloud world, we do this awkward
>> “Let me stick the file in Zookeeper directly, avoiding Solr, and then do a
>> collection RELOAD” to push out the file everywhere. [1] It works! But
>> it’s just awkward.
>>
>> It’s great to know that I’ll be able to change out this awkward process
>> using these magic parameters to configSet. Even nicer would be to just
>> wrap the overwrite=true&cleanup=false and the Zip requirement into
>> something that sets those.
>>
>>
>> [1]
>> https://github.com/querqy/chorus/blob/master/smui/conf/smui2solrcloud.sh#L37
>>
>> On Sep 23, 2020, at 11:57 PM, Tomás Fernández Löbbe <
>> tomasflobbe@gmail.com> wrote:
>>
>> > Hmmm; seems the configSet API doesn't have an API to update a single
>> file! I wonder if uploading a configSet to the same name effectively
>> overwrites newly updated files but does not delete the existing files?
>> I've been working on this recently. As of 8.7, the UPLOAD command
>> supports overwriting (before, an UPLOAD on an existing configset name would
>> fail with BAD_REQUEST) and you can choose to cleanup or not the extra files
>> with the "cleanup" parameter.
>> You could upload a single file if you say overwrite=true&cleanup=false,
>> but it would still need to be in a zip file (and needs to be located in the
>> right path of the zip, for example, a synonyms file may be in
>> lang/synonyms_foo.txt or something)
>>
>> On Wed, Sep 23, 2020 at 8:10 PM David Smiley <dsmiley@apache.org> wrote:
>>
>>> +1 to deprecate managed resources in lieu of easier to maintain (and
>>> more flexible) file based GET/PUT into the configset.
>>>
>>> > I don't know if 9 is too soon from a deprecation stand point
>>>
>>> IMO it's never too soon as long as there is a deprecated release. Users
>>> take their time upgrading to major versions.
>>>
>>> > How much harder are the use-cases currently covered by managed
>>> resources, if that module was removed?
>>>
>>> I believe in practice, users synchronize one-way from their DB to Solr
>>> if they have dynamic resources like this. This is true where I work.
>>> Otherwise, they would probably be using Solr as the source of truth, which
>>> doesn't seem architecturally-sound for most apps IMO. Those users
>>> (hopefully few) would have to spend some time re-engineering the approach.
>>> Given one-way sync, the transition here is pretty easy: serialize the
>>> client-managed data to the right Solr format (stopwords vs synonyms vs ...)
>>> and then a file upload to Solr/ZK and then telling Solr which collections
>>> to "reload".
>>>
>>> Hmmm; seems the configSet API doesn't have an API to update a single
>>> file! I wonder if uploading a configSet to the same name effectively
>>> overwrites newly updated files but does not delete the existing files?
>>>
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley
>>>
>>>
>>> On Wed, Sep 23, 2020 at 10:28 AM Timothy Potter <thelabdude@gmail.com>
>>> wrote:
>>>
>>>> I agree we should deprecate the managed resources feature, it was the
>>>> first thing I was asked to build by LW nearly 7 years ago, before I was a
>>>> committer. Restlet was already in place and I built on top of that, not
>>>> sure who introduced it originally (nor do I care). Clearly from the vantage
>>>> point of looking back, JAX-RS and Jersey won the day with REST in Java but
>>>> that simply wasn't the case back then. What's important is how we move
>>>> forward vs. bestowing judgement backed by wisdom of hindsight on decisions
>>>> made many years ago.
>>>>
>>>> In the short term, does Apache have an Artifactory (or similar) where
>>>> we can host the Restlet dependencies for Github to pull them from? If not,
>>>> then we can port the code that's using Restlet over to using JAX-RS /
>>>> Jersey. Personally I'd prefer we remove Managed Resources support from 9
>>>> instead of porting the Restlet code but I don't know if 9 is too soon from
>>>> a deprecation stand point?
>>>>
>>>> Tim
>>>>
>>>>
>>>> On Mon, Sep 21, 2020 at 11:33 PM Noble Paul <noble.paul@gmail.com>
>>>> wrote:
>>>>
>>>>> We should deprecate that feature and remove restlet dependency
>>>>> altogether
>>>>>
>>>>> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein <joelsolr@gmail.com>
>>>>> wrote:
>>>>> >
>>>>> > Restlet again!!!!!!!
>>>>> >
>>>>> >
>>>>> >
>>>>> > Joel Bernstein
>>>>> > http://joelsolr.blogspot.com/
>>>>> >
>>>>> >
>>>>> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <
>>>>> epugh@opensourceconnections.com> wrote:
>>>>> >>
>>>>> >> Do we have a community blessed alternative to restlet already?
>>>>> >>
>>>>> >> On Sep 20, 2020, at 9:40 AM, Noble Paul <noble.paul@gmail.com>
>>>>> wrote:
>>>>> >>
>>>>> >> Haha.
>>>>> >>
>>>>> >> In fact schema APIs don't use restlet. Only the managed resources
>>>>> use it
>>>>> >>
>>>>> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>> >>>
>>>>> >>> If I were talend, I'd immediately start publishing to maven
>>>>> central. If I were the developer who built the schema APIs, I would never
>>>>> have used restlet to begin with.
>>>>> >>>
>>>>> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, <uwe@thetaphi.de>
>>>>> wrote:
>>>>> >>>>
>>>>> >>>> I was thinking the same. Because GitHub does not cache the
>>>>> downloaded artifacts like our jenkins servers.
>>>>> >>>>
>>>>> >>>> It seems to run it in a new VM or container every time, so it
>>>>> downloads all artifacts. If I were Talend, I'd also block this.
>>>>> >>>>
>>>>> >>>> Uwe
>>>>> >>>>
>>>>> >>>> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
>>>>> dawid.weiss@gmail.com>:
>>>>> >>>>>
>>>>> >>>>> I don't think it's http/https - I believe restlet repository
>>>>> simply
>>>>> >>>>> bans github servers because of excessive traffic? These URLs
>>>>> work for
>>>>> >>>>> me locally...
>>>>> >>>>>
>>>>> >>>>> Dawid
>>>>> >>>>>
>>>>> >>>>> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
>>>>> >>>>> LONDON) <cpoerschke@bloomberg.net> wrote:
>>>>> >>>>>>
>>>>> >>>>>>
>>>>> >>>>>> This sounds vaguely familiar. "http works, https does not
>>>>> work" and https://issues.apache.org/jira/browse/SOLR-13756 possibly
>>>>> related?
>>>>> >>>>>>
>>>>> >>>>>> From: dev@lucene.apache.org At: 09/18/20 10:01:29
>>>>> >>>>>> To: dev@lucene.apache.org
>>>>> >>>>>> Subject: Re: restlet dependencies
>>>>> >>>>>>
>>>>> >>>>>> I don't think it is, sadly.
>>>>> >>>>>> https://repo1.maven.org/maven2/org/restlet
>>>>> >>>>>>
>>>>> >>>>>> The link you provided (mvnrepository) aggregates from several
>>>>> maven
>>>>> >>>>>> repositories.
>>>>> >>>>>>
>>>>> >>>>>>
>>>>> >>>>>> D.
>>>>> >>>>>>
>>>>> >>>>>> On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
>>>>> >>>>>> <ichattopadhyaya@gmail.com> wrote:
>>>>> >>>>>>>
>>>>> >>>>>>>
>>>>> >>>>>>> Sorry, afk, but I heard (*hearsay*) that restlet is also on
>>>>> maven central
>>>>> >>>>>>
>>>>> >>>>>> these days. Can we confirm and switch to that? Sorry, if that's
>>>>> not the case.
>>>>> >>>>>>>
>>>>> >>>>>>>
>>>>> >>>>>>> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <
>>>>> dawid.weiss@gmail.com> wrote:
>>>>> >>>>>>>>
>>>>> >>>>>>>>
>>>>> >>>>>>>> Just FYI: can't get PR builds on github to work recently
>>>>> because of this:
>>>>> >>>>>>>>
>>>>> >>>>>>>>> Could not resolve all files for configuration
>>>>> >>>>>>
>>>>> >>>>>> ':solr:core:compileClasspath'.
>>>>> >>>>>>>>
>>>>> >>>>>>>> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>>>>> >>>>>>>> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>>>>> >>>>>>>> 351 > Could not get resource
>>>>> >>>>>>>>
>>>>> >>>>>> '
>>>>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>>>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>>>>> >>>>>>>>
>>>>> >>>>>>>> 352 > Could not GET
>>>>> >>>>>>>>
>>>>> >>>>>> '
>>>>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>>>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>>>>> >>>>>>>>
>>>>> >>>>>>>> 353 > Connection reset
>>>>> >>>>>>>> 354 > Could not download org.restlet-2.4.3.jar
>>>>> >>>>>>>> (org.restlet.jee:org.restlet:2.4.3)
>>>>> >>>>>>>> 355 > Could not get resource
>>>>> >>>>>>>>
>>>>> >>>>>> '
>>>>> https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
>>>>> >>>>>> ar'.
>>>>> >>>>>>>>
>>>>> >>>>>>>> 356 > Could not GET
>>>>> >>>>>>>>
>>>>> >>>>>> '
>>>>> https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
>>>>> >>>>>> 2.4.3.jar'.
>>>>> >>>>>>>>
>>>>> >>>>>>>> 357 > Connection reset
>>>>> >>>>>>>>
>>>>> >>>>>>>> D.
>>>>> >>>>>>>> ________________________________
>>>>> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>> >>>>>>>>
>>>>> >>>>>> ________________________________
>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>> >>>>>>
>>>>> >>>>>>
>>>>> >>>>> ________________________________
>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>> >>>>>
>>>>> >>>>
>>>>> >>>> --
>>>>> >>>> Uwe Schindler
>>>>> >>>> Achterdiek 19, 28357 Bremen
>>>>> >>>> https://www.thetaphi.de
>>>>> >>
>>>>> >>
>>>>> >> _______________________
>>>>> >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
>>>>> 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>>>>> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>>>> >> This e-mail and all contents, including attachments, is considered
>>>>> to be Company Confidential unless explicitly stated otherwise, regardless
>>>>> of whether attachments are marked as such.
>>>>> >>
>>>>>
>>>>>
>>>>> --
>>>>> -----------------------------------------------------
>>>>> Noble Paul
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>>
>> _______________________
>> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
>> | http://www.opensourceconnections.com | My Free/Busy
>> <http://tinyurl.com/eric-cal>
>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>> This e-mail and all contents, including attachments, is considered to be
>> Company Confidential unless explicitly stated otherwise, regardless
>> of whether attachments are marked as such.
>>
>>
Re: restlet dependencies [ In reply to ]
Ishan: can you be more specific please? How is it less secure or harder to
secure than, say, a configSet upload (internally multiple files)?

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Thu, Sep 24, 2020 at 1:53 PM Ishan Chattopadhyaya <
ichattopadhyaya@gmail.com> wrote:

> Single file update capability is a security nightmare. Even if it can be
> done, it should be supported only once authc/authz have been enabled.
>
> On Thu, 24 Sep, 2020, 10:16 pm Tomás Fernández Löbbe, <
> tomasflobbe@gmail.com> wrote:
>
>> I won't step in the way of a single file update. I haven't needed it so
>> far though. I usually have the configsets in a Git repo (all the configset
>> together) and I have a simple bash script that essentialy what's described
>> in the docs[1]: Generate the zip on the fly and upload (optionally set the
>> auth too). This can become a problem with big zips, but then again,
>> ZooKeeper limits the size of the configs, so far it hasn't been an issue
>> for me.
>>
>>
>> [1]
>> https://lucene.apache.org/solr/guide/8_6/configsets-api.html#configsets-upload
>>
>> On Thu, Sep 24, 2020 at 7:13 AM Eric Pugh <
>> epugh@opensourceconnections.com> wrote:
>>
>>> It would be great if we had a simple API for updating a file in a
>>> configset that didn’t assume you were just uploading a zip file.
>>>
>>> As an example use case, if you use the Querqy library, you need to
>>> deploy a “rules.txt” file, which in olden days just went on the filesystem
>>> and you would click reload on a core. In the SolrCloud world, we do this
>>> awkward “Let me stick the file in Zookeeper directly, avoiding Solr, and
>>> then do a collection RELOAD” to push out the file everywhere. [1] It
>>> works! But it’s just awkward.
>>>
>>> It’s great to know that I’ll be able to change out this awkward process
>>> using these magic parameters to configSet. Even nicer would be to just
>>> wrap the overwrite=true&cleanup=false and the Zip requirement into
>>> something that sets those.
>>>
>>>
>>> [1]
>>> https://github.com/querqy/chorus/blob/master/smui/conf/smui2solrcloud.sh#L37
>>>
>>> On Sep 23, 2020, at 11:57 PM, Tomás Fernández Löbbe <
>>> tomasflobbe@gmail.com> wrote:
>>>
>>> > Hmmm; seems the configSet API doesn't have an API to update a single
>>> file! I wonder if uploading a configSet to the same name effectively
>>> overwrites newly updated files but does not delete the existing files?
>>> I've been working on this recently. As of 8.7, the UPLOAD command
>>> supports overwriting (before, an UPLOAD on an existing configset name would
>>> fail with BAD_REQUEST) and you can choose to cleanup or not the extra files
>>> with the "cleanup" parameter.
>>> You could upload a single file if you say overwrite=true&cleanup=false,
>>> but it would still need to be in a zip file (and needs to be located in the
>>> right path of the zip, for example, a synonyms file may be in
>>> lang/synonyms_foo.txt or something)
>>>
>>> On Wed, Sep 23, 2020 at 8:10 PM David Smiley <dsmiley@apache.org> wrote:
>>>
>>>> +1 to deprecate managed resources in lieu of easier to maintain (and
>>>> more flexible) file based GET/PUT into the configset.
>>>>
>>>> > I don't know if 9 is too soon from a deprecation stand point
>>>>
>>>> IMO it's never too soon as long as there is a deprecated release.
>>>> Users take their time upgrading to major versions.
>>>>
>>>> > How much harder are the use-cases currently covered by managed
>>>> resources, if that module was removed?
>>>>
>>>> I believe in practice, users synchronize one-way from their DB to Solr
>>>> if they have dynamic resources like this. This is true where I work.
>>>> Otherwise, they would probably be using Solr as the source of truth, which
>>>> doesn't seem architecturally-sound for most apps IMO. Those users
>>>> (hopefully few) would have to spend some time re-engineering the approach.
>>>> Given one-way sync, the transition here is pretty easy: serialize the
>>>> client-managed data to the right Solr format (stopwords vs synonyms vs ...)
>>>> and then a file upload to Solr/ZK and then telling Solr which collections
>>>> to "reload".
>>>>
>>>> Hmmm; seems the configSet API doesn't have an API to update a single
>>>> file! I wonder if uploading a configSet to the same name effectively
>>>> overwrites newly updated files but does not delete the existing files?
>>>>
>>>> ~ David Smiley
>>>> Apache Lucene/Solr Search Developer
>>>> http://www.linkedin.com/in/davidwsmiley
>>>>
>>>>
>>>> On Wed, Sep 23, 2020 at 10:28 AM Timothy Potter <thelabdude@gmail.com>
>>>> wrote:
>>>>
>>>>> I agree we should deprecate the managed resources feature, it was the
>>>>> first thing I was asked to build by LW nearly 7 years ago, before I was a
>>>>> committer. Restlet was already in place and I built on top of that, not
>>>>> sure who introduced it originally (nor do I care). Clearly from the vantage
>>>>> point of looking back, JAX-RS and Jersey won the day with REST in Java but
>>>>> that simply wasn't the case back then. What's important is how we move
>>>>> forward vs. bestowing judgement backed by wisdom of hindsight on decisions
>>>>> made many years ago.
>>>>>
>>>>> In the short term, does Apache have an Artifactory (or similar) where
>>>>> we can host the Restlet dependencies for Github to pull them from? If not,
>>>>> then we can port the code that's using Restlet over to using JAX-RS /
>>>>> Jersey. Personally I'd prefer we remove Managed Resources support from 9
>>>>> instead of porting the Restlet code but I don't know if 9 is too soon from
>>>>> a deprecation stand point?
>>>>>
>>>>> Tim
>>>>>
>>>>>
>>>>> On Mon, Sep 21, 2020 at 11:33 PM Noble Paul <noble.paul@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> We should deprecate that feature and remove restlet dependency
>>>>>> altogether
>>>>>>
>>>>>> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein <joelsolr@gmail.com>
>>>>>> wrote:
>>>>>> >
>>>>>> > Restlet again!!!!!!!
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > Joel Bernstein
>>>>>> > http://joelsolr.blogspot.com/
>>>>>> >
>>>>>> >
>>>>>> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <
>>>>>> epugh@opensourceconnections.com> wrote:
>>>>>> >>
>>>>>> >> Do we have a community blessed alternative to restlet already?
>>>>>> >>
>>>>>> >> On Sep 20, 2020, at 9:40 AM, Noble Paul <noble.paul@gmail.com>
>>>>>> wrote:
>>>>>> >>
>>>>>> >> Haha.
>>>>>> >>
>>>>>> >> In fact schema APIs don't use restlet. Only the managed resources
>>>>>> use it
>>>>>> >>
>>>>>> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>> >>>
>>>>>> >>> If I were talend, I'd immediately start publishing to maven
>>>>>> central. If I were the developer who built the schema APIs, I would never
>>>>>> have used restlet to begin with.
>>>>>> >>>
>>>>>> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, <uwe@thetaphi.de>
>>>>>> wrote:
>>>>>> >>>>
>>>>>> >>>> I was thinking the same. Because GitHub does not cache the
>>>>>> downloaded artifacts like our jenkins servers.
>>>>>> >>>>
>>>>>> >>>> It seems to run it in a new VM or container every time, so it
>>>>>> downloads all artifacts. If I were Talend, I'd also block this.
>>>>>> >>>>
>>>>>> >>>> Uwe
>>>>>> >>>>
>>>>>> >>>> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
>>>>>> dawid.weiss@gmail.com>:
>>>>>> >>>>>
>>>>>> >>>>> I don't think it's http/https - I believe restlet repository
>>>>>> simply
>>>>>> >>>>> bans github servers because of excessive traffic? These URLs
>>>>>> work for
>>>>>> >>>>> me locally...
>>>>>> >>>>>
>>>>>> >>>>> Dawid
>>>>>> >>>>>
>>>>>> >>>>> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
>>>>>> >>>>> LONDON) <cpoerschke@bloomberg.net> wrote:
>>>>>> >>>>>>
>>>>>> >>>>>>
>>>>>> >>>>>> This sounds vaguely familiar. "http works, https does not
>>>>>> work" and https://issues.apache.org/jira/browse/SOLR-13756 possibly
>>>>>> related?
>>>>>> >>>>>>
>>>>>> >>>>>> From: dev@lucene.apache.org At: 09/18/20 10:01:29
>>>>>> >>>>>> To: dev@lucene.apache.org
>>>>>> >>>>>> Subject: Re: restlet dependencies
>>>>>> >>>>>>
>>>>>> >>>>>> I don't think it is, sadly.
>>>>>> >>>>>> https://repo1.maven.org/maven2/org/restlet
>>>>>> >>>>>>
>>>>>> >>>>>> The link you provided (mvnrepository) aggregates from several
>>>>>> maven
>>>>>> >>>>>> repositories.
>>>>>> >>>>>>
>>>>>> >>>>>>
>>>>>> >>>>>> D.
>>>>>> >>>>>>
>>>>>> >>>>>> On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
>>>>>> >>>>>> <ichattopadhyaya@gmail.com> wrote:
>>>>>> >>>>>>>
>>>>>> >>>>>>>
>>>>>> >>>>>>> Sorry, afk, but I heard (*hearsay*) that restlet is also on
>>>>>> maven central
>>>>>> >>>>>>
>>>>>> >>>>>> these days. Can we confirm and switch to that? Sorry, if
>>>>>> that's not the case.
>>>>>> >>>>>>>
>>>>>> >>>>>>>
>>>>>> >>>>>>> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <
>>>>>> dawid.weiss@gmail.com> wrote:
>>>>>> >>>>>>>>
>>>>>> >>>>>>>>
>>>>>> >>>>>>>> Just FYI: can't get PR builds on github to work recently
>>>>>> because of this:
>>>>>> >>>>>>>>
>>>>>> >>>>>>>>> Could not resolve all files for configuration
>>>>>> >>>>>>
>>>>>> >>>>>> ':solr:core:compileClasspath'.
>>>>>> >>>>>>>>
>>>>>> >>>>>>>> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>>>>>> >>>>>>>> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>>>>>> >>>>>>>> 351 > Could not get resource
>>>>>> >>>>>>>>
>>>>>> >>>>>> '
>>>>>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>>>>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>>>>>> >>>>>>>>
>>>>>> >>>>>>>> 352 > Could not GET
>>>>>> >>>>>>>>
>>>>>> >>>>>> '
>>>>>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>>>>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>>>>>> >>>>>>>>
>>>>>> >>>>>>>> 353 > Connection reset
>>>>>> >>>>>>>> 354 > Could not download org.restlet-2.4.3.jar
>>>>>> >>>>>>>> (org.restlet.jee:org.restlet:2.4.3)
>>>>>> >>>>>>>> 355 > Could not get resource
>>>>>> >>>>>>>>
>>>>>> >>>>>> '
>>>>>> https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
>>>>>> >>>>>> ar'.
>>>>>> >>>>>>>>
>>>>>> >>>>>>>> 356 > Could not GET
>>>>>> >>>>>>>>
>>>>>> >>>>>> '
>>>>>> https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
>>>>>> >>>>>> 2.4.3.jar'.
>>>>>> >>>>>>>>
>>>>>> >>>>>>>> 357 > Connection reset
>>>>>> >>>>>>>>
>>>>>> >>>>>>>> D.
>>>>>> >>>>>>>> ________________________________
>>>>>> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>> >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>> >>>>>>>>
>>>>>> >>>>>> ________________________________
>>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>> >>>>>>
>>>>>> >>>>>>
>>>>>> >>>>> ________________________________
>>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>> >>>>>
>>>>>> >>>>
>>>>>> >>>> --
>>>>>> >>>> Uwe Schindler
>>>>>> >>>> Achterdiek 19, 28357 Bremen
>>>>>> >>>> https://www.thetaphi.de
>>>>>> >>
>>>>>> >>
>>>>>> >> _______________________
>>>>>> >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
>>>>>> 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>>>>>> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>>>>> >> This e-mail and all contents, including attachments, is considered
>>>>>> to be Company Confidential unless explicitly stated otherwise, regardless
>>>>>> of whether attachments are marked as such.
>>>>>> >>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> -----------------------------------------------------
>>>>>> Noble Paul
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>
>>>>>>
>>> _______________________
>>> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
>>> | http://www.opensourceconnections.com | My Free/Busy
>>> <http://tinyurl.com/eric-cal>
>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>>> This e-mail and all contents, including attachments, is considered to be
>>> Company Confidential unless explicitly stated otherwise, regardless
>>> of whether attachments are marked as such.
>>>
>>>
Re: restlet dependencies [ In reply to ]
An entire configset, when uploaded via api without security enabled, is
marked untrusted. When creating a collection from untrusted configset,
certain vulnerable components can't be initialized.

On Fri, 25 Sep, 2020, 9:04 am David Smiley, <dsmiley@apache.org> wrote:

> Ishan: can you be more specific please? How is it less secure or harder
> to secure than, say, a configSet upload (internally multiple files)?
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Thu, Sep 24, 2020 at 1:53 PM Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
>
>> Single file update capability is a security nightmare. Even if it can be
>> done, it should be supported only once authc/authz have been enabled.
>>
>> On Thu, 24 Sep, 2020, 10:16 pm Tomás Fernández Löbbe, <
>> tomasflobbe@gmail.com> wrote:
>>
>>> I won't step in the way of a single file update. I haven't needed it so
>>> far though. I usually have the configsets in a Git repo (all the configset
>>> together) and I have a simple bash script that essentialy what's described
>>> in the docs[1]: Generate the zip on the fly and upload (optionally set the
>>> auth too). This can become a problem with big zips, but then again,
>>> ZooKeeper limits the size of the configs, so far it hasn't been an issue
>>> for me.
>>>
>>>
>>> [1]
>>> https://lucene.apache.org/solr/guide/8_6/configsets-api.html#configsets-upload
>>>
>>> On Thu, Sep 24, 2020 at 7:13 AM Eric Pugh <
>>> epugh@opensourceconnections.com> wrote:
>>>
>>>> It would be great if we had a simple API for updating a file in a
>>>> configset that didn’t assume you were just uploading a zip file.
>>>>
>>>> As an example use case, if you use the Querqy library, you need to
>>>> deploy a “rules.txt” file, which in olden days just went on the filesystem
>>>> and you would click reload on a core. In the SolrCloud world, we do this
>>>> awkward “Let me stick the file in Zookeeper directly, avoiding Solr, and
>>>> then do a collection RELOAD” to push out the file everywhere. [1] It
>>>> works! But it’s just awkward.
>>>>
>>>> It’s great to know that I’ll be able to change out this awkward process
>>>> using these magic parameters to configSet. Even nicer would be to just
>>>> wrap the overwrite=true&cleanup=false and the Zip requirement into
>>>> something that sets those.
>>>>
>>>>
>>>> [1]
>>>> https://github.com/querqy/chorus/blob/master/smui/conf/smui2solrcloud.sh#L37
>>>>
>>>> On Sep 23, 2020, at 11:57 PM, Tomás Fernández Löbbe <
>>>> tomasflobbe@gmail.com> wrote:
>>>>
>>>> > Hmmm; seems the configSet API doesn't have an API to update a single
>>>> file! I wonder if uploading a configSet to the same name effectively
>>>> overwrites newly updated files but does not delete the existing files?
>>>> I've been working on this recently. As of 8.7, the UPLOAD command
>>>> supports overwriting (before, an UPLOAD on an existing configset name would
>>>> fail with BAD_REQUEST) and you can choose to cleanup or not the extra files
>>>> with the "cleanup" parameter.
>>>> You could upload a single file if you say overwrite=true&cleanup=false,
>>>> but it would still need to be in a zip file (and needs to be located in the
>>>> right path of the zip, for example, a synonyms file may be in
>>>> lang/synonyms_foo.txt or something)
>>>>
>>>> On Wed, Sep 23, 2020 at 8:10 PM David Smiley <dsmiley@apache.org>
>>>> wrote:
>>>>
>>>>> +1 to deprecate managed resources in lieu of easier to maintain (and
>>>>> more flexible) file based GET/PUT into the configset.
>>>>>
>>>>> > I don't know if 9 is too soon from a deprecation stand point
>>>>>
>>>>> IMO it's never too soon as long as there is a deprecated release.
>>>>> Users take their time upgrading to major versions.
>>>>>
>>>>> > How much harder are the use-cases currently covered by managed
>>>>> resources, if that module was removed?
>>>>>
>>>>> I believe in practice, users synchronize one-way from their DB to Solr
>>>>> if they have dynamic resources like this. This is true where I work.
>>>>> Otherwise, they would probably be using Solr as the source of truth, which
>>>>> doesn't seem architecturally-sound for most apps IMO. Those users
>>>>> (hopefully few) would have to spend some time re-engineering the approach.
>>>>> Given one-way sync, the transition here is pretty easy: serialize the
>>>>> client-managed data to the right Solr format (stopwords vs synonyms vs ...)
>>>>> and then a file upload to Solr/ZK and then telling Solr which collections
>>>>> to "reload".
>>>>>
>>>>> Hmmm; seems the configSet API doesn't have an API to update a single
>>>>> file! I wonder if uploading a configSet to the same name effectively
>>>>> overwrites newly updated files but does not delete the existing files?
>>>>>
>>>>> ~ David Smiley
>>>>> Apache Lucene/Solr Search Developer
>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>
>>>>>
>>>>> On Wed, Sep 23, 2020 at 10:28 AM Timothy Potter <thelabdude@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I agree we should deprecate the managed resources feature, it was the
>>>>>> first thing I was asked to build by LW nearly 7 years ago, before I was a
>>>>>> committer. Restlet was already in place and I built on top of that, not
>>>>>> sure who introduced it originally (nor do I care). Clearly from the vantage
>>>>>> point of looking back, JAX-RS and Jersey won the day with REST in Java but
>>>>>> that simply wasn't the case back then. What's important is how we move
>>>>>> forward vs. bestowing judgement backed by wisdom of hindsight on decisions
>>>>>> made many years ago.
>>>>>>
>>>>>> In the short term, does Apache have an Artifactory (or similar) where
>>>>>> we can host the Restlet dependencies for Github to pull them from? If not,
>>>>>> then we can port the code that's using Restlet over to using JAX-RS /
>>>>>> Jersey. Personally I'd prefer we remove Managed Resources support from 9
>>>>>> instead of porting the Restlet code but I don't know if 9 is too soon from
>>>>>> a deprecation stand point?
>>>>>>
>>>>>> Tim
>>>>>>
>>>>>>
>>>>>> On Mon, Sep 21, 2020 at 11:33 PM Noble Paul <noble.paul@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> We should deprecate that feature and remove restlet dependency
>>>>>>> altogether
>>>>>>>
>>>>>>> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein <joelsolr@gmail.com>
>>>>>>> wrote:
>>>>>>> >
>>>>>>> > Restlet again!!!!!!!
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > Joel Bernstein
>>>>>>> > http://joelsolr.blogspot.com/
>>>>>>> >
>>>>>>> >
>>>>>>> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <
>>>>>>> epugh@opensourceconnections.com> wrote:
>>>>>>> >>
>>>>>>> >> Do we have a community blessed alternative to restlet already?
>>>>>>> >>
>>>>>>> >> On Sep 20, 2020, at 9:40 AM, Noble Paul <noble.paul@gmail.com>
>>>>>>> wrote:
>>>>>>> >>
>>>>>>> >> Haha.
>>>>>>> >>
>>>>>>> >> In fact schema APIs don't use restlet. Only the managed resources
>>>>>>> use it
>>>>>>> >>
>>>>>>> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
>>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>>> >>>
>>>>>>> >>> If I were talend, I'd immediately start publishing to maven
>>>>>>> central. If I were the developer who built the schema APIs, I would never
>>>>>>> have used restlet to begin with.
>>>>>>> >>>
>>>>>>> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, <uwe@thetaphi.de>
>>>>>>> wrote:
>>>>>>> >>>>
>>>>>>> >>>> I was thinking the same. Because GitHub does not cache the
>>>>>>> downloaded artifacts like our jenkins servers.
>>>>>>> >>>>
>>>>>>> >>>> It seems to run it in a new VM or container every time, so it
>>>>>>> downloads all artifacts. If I were Talend, I'd also block this.
>>>>>>> >>>>
>>>>>>> >>>> Uwe
>>>>>>> >>>>
>>>>>>> >>>> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
>>>>>>> dawid.weiss@gmail.com>:
>>>>>>> >>>>>
>>>>>>> >>>>> I don't think it's http/https - I believe restlet repository
>>>>>>> simply
>>>>>>> >>>>> bans github servers because of excessive traffic? These URLs
>>>>>>> work for
>>>>>>> >>>>> me locally...
>>>>>>> >>>>>
>>>>>>> >>>>> Dawid
>>>>>>> >>>>>
>>>>>>> >>>>> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
>>>>>>> >>>>> LONDON) <cpoerschke@bloomberg.net> wrote:
>>>>>>> >>>>>>
>>>>>>> >>>>>>
>>>>>>> >>>>>> This sounds vaguely familiar. "http works, https does not
>>>>>>> work" and https://issues.apache.org/jira/browse/SOLR-13756 possibly
>>>>>>> related?
>>>>>>> >>>>>>
>>>>>>> >>>>>> From: dev@lucene.apache.org At: 09/18/20 10:01:29
>>>>>>> >>>>>> To: dev@lucene.apache.org
>>>>>>> >>>>>> Subject: Re: restlet dependencies
>>>>>>> >>>>>>
>>>>>>> >>>>>> I don't think it is, sadly.
>>>>>>> >>>>>> https://repo1.maven.org/maven2/org/restlet
>>>>>>> >>>>>>
>>>>>>> >>>>>> The link you provided (mvnrepository) aggregates from
>>>>>>> several maven
>>>>>>> >>>>>> repositories.
>>>>>>> >>>>>>
>>>>>>> >>>>>>
>>>>>>> >>>>>> D.
>>>>>>> >>>>>>
>>>>>>> >>>>>> On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
>>>>>>> >>>>>> <ichattopadhyaya@gmail.com> wrote:
>>>>>>> >>>>>>>
>>>>>>> >>>>>>>
>>>>>>> >>>>>>> Sorry, afk, but I heard (*hearsay*) that restlet is also on
>>>>>>> maven central
>>>>>>> >>>>>>
>>>>>>> >>>>>> these days. Can we confirm and switch to that? Sorry, if
>>>>>>> that's not the case.
>>>>>>> >>>>>>>
>>>>>>> >>>>>>>
>>>>>>> >>>>>>> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <
>>>>>>> dawid.weiss@gmail.com> wrote:
>>>>>>> >>>>>>>>
>>>>>>> >>>>>>>>
>>>>>>> >>>>>>>> Just FYI: can't get PR builds on github to work recently
>>>>>>> because of this:
>>>>>>> >>>>>>>>
>>>>>>> >>>>>>>>> Could not resolve all files for configuration
>>>>>>> >>>>>>
>>>>>>> >>>>>> ':solr:core:compileClasspath'.
>>>>>>> >>>>>>>>
>>>>>>> >>>>>>>> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>>>>>>> >>>>>>>> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>>>>>>> >>>>>>>> 351 > Could not get resource
>>>>>>> >>>>>>>>
>>>>>>> >>>>>> '
>>>>>>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>>>>>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>>>>>>> >>>>>>>>
>>>>>>> >>>>>>>> 352 > Could not GET
>>>>>>> >>>>>>>>
>>>>>>> >>>>>> '
>>>>>>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>>>>>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>>>>>>> >>>>>>>>
>>>>>>> >>>>>>>> 353 > Connection reset
>>>>>>> >>>>>>>> 354 > Could not download org.restlet-2.4.3.jar
>>>>>>> >>>>>>>> (org.restlet.jee:org.restlet:2.4.3)
>>>>>>> >>>>>>>> 355 > Could not get resource
>>>>>>> >>>>>>>>
>>>>>>> >>>>>> '
>>>>>>> https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
>>>>>>> >>>>>> ar'.
>>>>>>> >>>>>>>>
>>>>>>> >>>>>>>> 356 > Could not GET
>>>>>>> >>>>>>>>
>>>>>>> >>>>>> '
>>>>>>> https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
>>>>>>> >>>>>> 2.4.3.jar'.
>>>>>>> >>>>>>>>
>>>>>>> >>>>>>>> 357 > Connection reset
>>>>>>> >>>>>>>>
>>>>>>> >>>>>>>> D.
>>>>>>> >>>>>>>> ________________________________
>>>>>>> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>> >>>>>>>> For additional commands, e-mail:
>>>>>>> dev-help@lucene.apache.org
>>>>>>> >>>>>>>>
>>>>>>> >>>>>> ________________________________
>>>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>> >>>>>>
>>>>>>> >>>>>>
>>>>>>> >>>>> ________________________________
>>>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>> >>>>>
>>>>>>> >>>>
>>>>>>> >>>> --
>>>>>>> >>>> Uwe Schindler
>>>>>>> >>>> Achterdiek 19, 28357 Bremen
>>>>>>> >>>> https://www.thetaphi.de
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> _______________________
>>>>>>> >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
>>>>>>> 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>>>>>>> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>>>>>> >> This e-mail and all contents, including attachments, is
>>>>>>> considered to be Company Confidential unless explicitly stated otherwise,
>>>>>>> regardless of whether attachments are marked as such.
>>>>>>> >>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> -----------------------------------------------------
>>>>>>> Noble Paul
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>
>>>>>>>
>>>> _______________________
>>>> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
>>>> | http://www.opensourceconnections.com | My Free/Busy
>>>> <http://tinyurl.com/eric-cal>
>>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>>> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>>>> This e-mail and all contents, including attachments, is considered to
>>>> be Company Confidential unless explicitly stated otherwise, regardless
>>>> of whether attachments are marked as such.
>>>>
>>>>
Re: restlet dependencies [ In reply to ]
SOLR-5287 has some discussion. The changes were backed out due to security
reasons. Anyway, Eric, Tomas & David, let us not hijack this thread on
restlet and discuss something totally unrelated.

On Fri, 25 Sep, 2020, 9:20 am Ishan Chattopadhyaya, <
ichattopadhyaya@gmail.com> wrote:

> An entire configset, when uploaded via api without security enabled, is
> marked untrusted. When creating a collection from untrusted configset,
> certain vulnerable components can't be initialized.
>
> On Fri, 25 Sep, 2020, 9:04 am David Smiley, <dsmiley@apache.org> wrote:
>
>> Ishan: can you be more specific please? How is it less secure or harder
>> to secure than, say, a configSet upload (internally multiple files)?
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Thu, Sep 24, 2020 at 1:53 PM Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> wrote:
>>
>>> Single file update capability is a security nightmare. Even if it can be
>>> done, it should be supported only once authc/authz have been enabled.
>>>
>>> On Thu, 24 Sep, 2020, 10:16 pm Tomás Fernández Löbbe, <
>>> tomasflobbe@gmail.com> wrote:
>>>
>>>> I won't step in the way of a single file update. I haven't needed it so
>>>> far though. I usually have the configsets in a Git repo (all the configset
>>>> together) and I have a simple bash script that essentialy what's described
>>>> in the docs[1]: Generate the zip on the fly and upload (optionally set the
>>>> auth too). This can become a problem with big zips, but then again,
>>>> ZooKeeper limits the size of the configs, so far it hasn't been an issue
>>>> for me.
>>>>
>>>>
>>>> [1]
>>>> https://lucene.apache.org/solr/guide/8_6/configsets-api.html#configsets-upload
>>>>
>>>> On Thu, Sep 24, 2020 at 7:13 AM Eric Pugh <
>>>> epugh@opensourceconnections.com> wrote:
>>>>
>>>>> It would be great if we had a simple API for updating a file in a
>>>>> configset that didn’t assume you were just uploading a zip file.
>>>>>
>>>>> As an example use case, if you use the Querqy library, you need to
>>>>> deploy a “rules.txt” file, which in olden days just went on the filesystem
>>>>> and you would click reload on a core. In the SolrCloud world, we do this
>>>>> awkward “Let me stick the file in Zookeeper directly, avoiding Solr, and
>>>>> then do a collection RELOAD” to push out the file everywhere. [1] It
>>>>> works! But it’s just awkward.
>>>>>
>>>>> It’s great to know that I’ll be able to change out this awkward
>>>>> process using these magic parameters to configSet. Even nicer would be to
>>>>> just wrap the overwrite=true&cleanup=false and the Zip requirement into
>>>>> something that sets those.
>>>>>
>>>>>
>>>>> [1]
>>>>> https://github.com/querqy/chorus/blob/master/smui/conf/smui2solrcloud.sh#L37
>>>>>
>>>>> On Sep 23, 2020, at 11:57 PM, Tomás Fernández Löbbe <
>>>>> tomasflobbe@gmail.com> wrote:
>>>>>
>>>>> > Hmmm; seems the configSet API doesn't have an API to update a single
>>>>> file! I wonder if uploading a configSet to the same name effectively
>>>>> overwrites newly updated files but does not delete the existing files?
>>>>> I've been working on this recently. As of 8.7, the UPLOAD command
>>>>> supports overwriting (before, an UPLOAD on an existing configset name would
>>>>> fail with BAD_REQUEST) and you can choose to cleanup or not the extra files
>>>>> with the "cleanup" parameter.
>>>>> You could upload a single file if you say
>>>>> overwrite=true&cleanup=false, but it would still need to be in a zip file
>>>>> (and needs to be located in the right path of the zip, for example, a
>>>>> synonyms file may be in lang/synonyms_foo.txt or something)
>>>>>
>>>>> On Wed, Sep 23, 2020 at 8:10 PM David Smiley <dsmiley@apache.org>
>>>>> wrote:
>>>>>
>>>>>> +1 to deprecate managed resources in lieu of easier to maintain (and
>>>>>> more flexible) file based GET/PUT into the configset.
>>>>>>
>>>>>> > I don't know if 9 is too soon from a deprecation stand point
>>>>>>
>>>>>> IMO it's never too soon as long as there is a deprecated release.
>>>>>> Users take their time upgrading to major versions.
>>>>>>
>>>>>> > How much harder are the use-cases currently covered by managed
>>>>>> resources, if that module was removed?
>>>>>>
>>>>>> I believe in practice, users synchronize one-way from their DB to
>>>>>> Solr if they have dynamic resources like this. This is true where I work.
>>>>>> Otherwise, they would probably be using Solr as the source of truth, which
>>>>>> doesn't seem architecturally-sound for most apps IMO. Those users
>>>>>> (hopefully few) would have to spend some time re-engineering the approach.
>>>>>> Given one-way sync, the transition here is pretty easy: serialize the
>>>>>> client-managed data to the right Solr format (stopwords vs synonyms vs ...)
>>>>>> and then a file upload to Solr/ZK and then telling Solr which collections
>>>>>> to "reload".
>>>>>>
>>>>>> Hmmm; seems the configSet API doesn't have an API to update a single
>>>>>> file! I wonder if uploading a configSet to the same name effectively
>>>>>> overwrites newly updated files but does not delete the existing files?
>>>>>>
>>>>>> ~ David Smiley
>>>>>> Apache Lucene/Solr Search Developer
>>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 23, 2020 at 10:28 AM Timothy Potter <thelabdude@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I agree we should deprecate the managed resources feature, it was
>>>>>>> the first thing I was asked to build by LW nearly 7 years ago, before I was
>>>>>>> a committer. Restlet was already in place and I built on top of that, not
>>>>>>> sure who introduced it originally (nor do I care). Clearly from the vantage
>>>>>>> point of looking back, JAX-RS and Jersey won the day with REST in Java but
>>>>>>> that simply wasn't the case back then. What's important is how we move
>>>>>>> forward vs. bestowing judgement backed by wisdom of hindsight on decisions
>>>>>>> made many years ago.
>>>>>>>
>>>>>>> In the short term, does Apache have an Artifactory (or similar)
>>>>>>> where we can host the Restlet dependencies for Github to pull them from? If
>>>>>>> not, then we can port the code that's using Restlet over to using JAX-RS /
>>>>>>> Jersey. Personally I'd prefer we remove Managed Resources support from 9
>>>>>>> instead of porting the Restlet code but I don't know if 9 is too soon from
>>>>>>> a deprecation stand point?
>>>>>>>
>>>>>>> Tim
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Sep 21, 2020 at 11:33 PM Noble Paul <noble.paul@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> We should deprecate that feature and remove restlet dependency
>>>>>>>> altogether
>>>>>>>>
>>>>>>>> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein <joelsolr@gmail.com>
>>>>>>>> wrote:
>>>>>>>> >
>>>>>>>> > Restlet again!!!!!!!
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > Joel Bernstein
>>>>>>>> > http://joelsolr.blogspot.com/
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <
>>>>>>>> epugh@opensourceconnections.com> wrote:
>>>>>>>> >>
>>>>>>>> >> Do we have a community blessed alternative to restlet already?
>>>>>>>> >>
>>>>>>>> >> On Sep 20, 2020, at 9:40 AM, Noble Paul <noble.paul@gmail.com>
>>>>>>>> wrote:
>>>>>>>> >>
>>>>>>>> >> Haha.
>>>>>>>> >>
>>>>>>>> >> In fact schema APIs don't use restlet. Only the managed
>>>>>>>> resources use it
>>>>>>>> >>
>>>>>>>> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
>>>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>>>> >>>
>>>>>>>> >>> If I were talend, I'd immediately start publishing to maven
>>>>>>>> central. If I were the developer who built the schema APIs, I would never
>>>>>>>> have used restlet to begin with.
>>>>>>>> >>>
>>>>>>>> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, <uwe@thetaphi.de>
>>>>>>>> wrote:
>>>>>>>> >>>>
>>>>>>>> >>>> I was thinking the same. Because GitHub does not cache the
>>>>>>>> downloaded artifacts like our jenkins servers.
>>>>>>>> >>>>
>>>>>>>> >>>> It seems to run it in a new VM or container every time, so it
>>>>>>>> downloads all artifacts. If I were Talend, I'd also block this.
>>>>>>>> >>>>
>>>>>>>> >>>> Uwe
>>>>>>>> >>>>
>>>>>>>> >>>> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
>>>>>>>> dawid.weiss@gmail.com>:
>>>>>>>> >>>>>
>>>>>>>> >>>>> I don't think it's http/https - I believe restlet repository
>>>>>>>> simply
>>>>>>>> >>>>> bans github servers because of excessive traffic? These URLs
>>>>>>>> work for
>>>>>>>> >>>>> me locally...
>>>>>>>> >>>>>
>>>>>>>> >>>>> Dawid
>>>>>>>> >>>>>
>>>>>>>> >>>>> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke
>>>>>>>> (BLOOMBERG/
>>>>>>>> >>>>> LONDON) <cpoerschke@bloomberg.net> wrote:
>>>>>>>> >>>>>>
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> This sounds vaguely familiar. "http works, https does not
>>>>>>>> work" and https://issues.apache.org/jira/browse/SOLR-13756
>>>>>>>> possibly related?
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> From: dev@lucene.apache.org At: 09/18/20 10:01:29
>>>>>>>> >>>>>> To: dev@lucene.apache.org
>>>>>>>> >>>>>> Subject: Re: restlet dependencies
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> I don't think it is, sadly.
>>>>>>>> >>>>>> https://repo1.maven.org/maven2/org/restlet
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> The link you provided (mvnrepository) aggregates from
>>>>>>>> several maven
>>>>>>>> >>>>>> repositories.
>>>>>>>> >>>>>>
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> D.
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
>>>>>>>> >>>>>> <ichattopadhyaya@gmail.com> wrote:
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>> Sorry, afk, but I heard (*hearsay*) that restlet is also
>>>>>>>> on maven central
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> these days. Can we confirm and switch to that? Sorry, if
>>>>>>>> that's not the case.
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <
>>>>>>>> dawid.weiss@gmail.com> wrote:
>>>>>>>> >>>>>>>>
>>>>>>>> >>>>>>>>
>>>>>>>> >>>>>>>> Just FYI: can't get PR builds on github to work recently
>>>>>>>> because of this:
>>>>>>>> >>>>>>>>
>>>>>>>> >>>>>>>>> Could not resolve all files for configuration
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> ':solr:core:compileClasspath'.
>>>>>>>> >>>>>>>>
>>>>>>>> >>>>>>>> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>>>>>>>> >>>>>>>> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>>>>>>>> >>>>>>>> 351 > Could not get resource
>>>>>>>> >>>>>>>>
>>>>>>>> >>>>>> '
>>>>>>>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>>>>>>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>>>>>>>> >>>>>>>>
>>>>>>>> >>>>>>>> 352 > Could not GET
>>>>>>>> >>>>>>>>
>>>>>>>> >>>>>> '
>>>>>>>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>>>>>>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>>>>>>>> >>>>>>>>
>>>>>>>> >>>>>>>> 353 > Connection reset
>>>>>>>> >>>>>>>> 354 > Could not download org.restlet-2.4.3.jar
>>>>>>>> >>>>>>>> (org.restlet.jee:org.restlet:2.4.3)
>>>>>>>> >>>>>>>> 355 > Could not get resource
>>>>>>>> >>>>>>>>
>>>>>>>> >>>>>> '
>>>>>>>> https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
>>>>>>>> >>>>>> ar'.
>>>>>>>> >>>>>>>>
>>>>>>>> >>>>>>>> 356 > Could not GET
>>>>>>>> >>>>>>>>
>>>>>>>> >>>>>> '
>>>>>>>> https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
>>>>>>>> >>>>>> 2.4.3.jar'.
>>>>>>>> >>>>>>>>
>>>>>>>> >>>>>>>> 357 > Connection reset
>>>>>>>> >>>>>>>>
>>>>>>>> >>>>>>>> D.
>>>>>>>> >>>>>>>> ________________________________
>>>>>>>> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>> >>>>>>>> For additional commands, e-mail:
>>>>>>>> dev-help@lucene.apache.org
>>>>>>>> >>>>>>>>
>>>>>>>> >>>>>> ________________________________
>>>>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>> >>>>>>
>>>>>>>> >>>>>>
>>>>>>>> >>>>> ________________________________
>>>>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>> >>>>>
>>>>>>>> >>>>
>>>>>>>> >>>> --
>>>>>>>> >>>> Uwe Schindler
>>>>>>>> >>>> Achterdiek 19, 28357 Bremen
>>>>>>>> >>>> https://www.thetaphi.de
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >> _______________________
>>>>>>>> >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
>>>>>>>> 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>>>>>>>> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>>>>>>> >> This e-mail and all contents, including attachments, is
>>>>>>>> considered to be Company Confidential unless explicitly stated otherwise,
>>>>>>>> regardless of whether attachments are marked as such.
>>>>>>>> >>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> -----------------------------------------------------
>>>>>>>> Noble Paul
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>>
>>>>>>>>
>>>>> _______________________
>>>>> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
>>>>> | http://www.opensourceconnections.com | My Free/Busy
>>>>> <http://tinyurl.com/eric-cal>
>>>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>>>> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>>>>> This e-mail and all contents, including attachments, is considered to
>>>>> be Company Confidential unless explicitly stated otherwise, regardless
>>>>> of whether attachments are marked as such.
>>>>>
>>>>>
Re: restlet dependencies [ In reply to ]
Yea, managed resources is one of the features I’ll not miss. It seemed smart back then, but for some reason I don’t think people use it that much, and I agree it makes more sense for the user to be aware of the configset and update the configset.

I’d appreciate a upload one file API. Ishan, you could say that you can upload a single file to a config set only if auth is enabled OR if the configset is already untrusted.

Jan

> 25. sep. 2020 kl. 06:02 skrev Ishan Chattopadhyaya <ichattopadhyaya@gmail.com>:
>
> SOLR-5287 has some discussion. The changes were backed out due to security reasons. Anyway, Eric, Tomas & David, let us not hijack this thread on restlet and discuss something totally unrelated.
>
> On Fri, 25 Sep, 2020, 9:20 am Ishan Chattopadhyaya, <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com>> wrote:
> An entire configset, when uploaded via api without security enabled, is marked untrusted. When creating a collection from untrusted configset, certain vulnerable components can't be initialized.
>
> On Fri, 25 Sep, 2020, 9:04 am David Smiley, <dsmiley@apache.org <mailto:dsmiley@apache.org>> wrote:
> Ishan: can you be more specific please? How is it less secure or harder to secure than, say, a configSet upload (internally multiple files)?
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley <http://www.linkedin.com/in/davidwsmiley>
>
> On Thu, Sep 24, 2020 at 1:53 PM Ishan Chattopadhyaya <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com>> wrote:
> Single file update capability is a security nightmare. Even if it can be done, it should be supported only once authc/authz have been enabled.
>
> On Thu, 24 Sep, 2020, 10:16 pm Tomás Fernández Löbbe, <tomasflobbe@gmail.com <mailto:tomasflobbe@gmail.com>> wrote:
> I won't step in the way of a single file update. I haven't needed it so far though. I usually have the configsets in a Git repo (all the configset together) and I have a simple bash script that essentialy what's described in the docs[1]: Generate the zip on the fly and upload (optionally set the auth too). This can become a problem with big zips, but then again, ZooKeeper limits the size of the configs, so far it hasn't been an issue for me.
>
>
> [1] https://lucene.apache.org/solr/guide/8_6/configsets-api.html#configsets-upload <https://lucene.apache.org/solr/guide/8_6/configsets-api.html#configsets-upload>
> On Thu, Sep 24, 2020 at 7:13 AM Eric Pugh <epugh@opensourceconnections.com <mailto:epugh@opensourceconnections.com>> wrote:
> It would be great if we had a simple API for updating a file in a configset that didn’t assume you were just uploading a zip file.
>
> As an example use case, if you use the Querqy library, you need to deploy a “rules.txt” file, which in olden days just went on the filesystem and you would click reload on a core. In the SolrCloud world, we do this awkward “Let me stick the file in Zookeeper directly, avoiding Solr, and then do a collection RELOAD” to push out the file everywhere. [1] It works! But it’s just awkward.
>
> It’s great to know that I’ll be able to change out this awkward process using these magic parameters to configSet. Even nicer would be to just wrap the overwrite=true&cleanup=false and the Zip requirement into something that sets those.
>
>
> [1] https://github.com/querqy/chorus/blob/master/smui/conf/smui2solrcloud.sh#L37 <https://github.com/querqy/chorus/blob/master/smui/conf/smui2solrcloud.sh#L37>
>
>> On Sep 23, 2020, at 11:57 PM, Tomás Fernández Löbbe <tomasflobbe@gmail.com <mailto:tomasflobbe@gmail.com>> wrote:
>>
>> > Hmmm; seems the configSet API doesn't have an API to update a single file! I wonder if uploading a configSet to the same name effectively overwrites newly updated files but does not delete the existing files?
>> I've been working on this recently. As of 8.7, the UPLOAD command supports overwriting (before, an UPLOAD on an existing configset name would fail with BAD_REQUEST) and you can choose to cleanup or not the extra files with the "cleanup" parameter.
>> You could upload a single file if you say overwrite=true&cleanup=false, but it would still need to be in a zip file (and needs to be located in the right path of the zip, for example, a synonyms file may be in lang/synonyms_foo.txt or something)
>>
>> On Wed, Sep 23, 2020 at 8:10 PM David Smiley <dsmiley@apache.org <mailto:dsmiley@apache.org>> wrote:
>> +1 to deprecate managed resources in lieu of easier to maintain (and more flexible) file based GET/PUT into the configset.
>>
>> > I don't know if 9 is too soon from a deprecation stand point
>>
>> IMO it's never too soon as long as there is a deprecated release. Users take their time upgrading to major versions.
>>
>> > How much harder are the use-cases currently covered by managed resources, if that module was removed?
>>
>> I believe in practice, users synchronize one-way from their DB to Solr if they have dynamic resources like this. This is true where I work. Otherwise, they would probably be using Solr as the source of truth, which doesn't seem architecturally-sound for most apps IMO. Those users (hopefully few) would have to spend some time re-engineering the approach. Given one-way sync, the transition here is pretty easy: serialize the client-managed data to the right Solr format (stopwords vs synonyms vs ...) and then a file upload to Solr/ZK and then telling Solr which collections to "reload".
>>
>> Hmmm; seems the configSet API doesn't have an API to update a single file! I wonder if uploading a configSet to the same name effectively overwrites newly updated files but does not delete the existing files?
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley <http://www.linkedin.com/in/davidwsmiley>
>>
>> On Wed, Sep 23, 2020 at 10:28 AM Timothy Potter <thelabdude@gmail.com <mailto:thelabdude@gmail.com>> wrote:
>> I agree we should deprecate the managed resources feature, it was the first thing I was asked to build by LW nearly 7 years ago, before I was a committer. Restlet was already in place and I built on top of that, not sure who introduced it originally (nor do I care). Clearly from the vantage point of looking back, JAX-RS and Jersey won the day with REST in Java but that simply wasn't the case back then. What's important is how we move forward vs. bestowing judgement backed by wisdom of hindsight on decisions made many years ago.
>>
>> In the short term, does Apache have an Artifactory (or similar) where we can host the Restlet dependencies for Github to pull them from? If not, then we can port the code that's using Restlet over to using JAX-RS / Jersey. Personally I'd prefer we remove Managed Resources support from 9 instead of porting the Restlet code but I don't know if 9 is too soon from a deprecation stand point?
>>
>> Tim
>>
>>
>> On Mon, Sep 21, 2020 at 11:33 PM Noble Paul <noble.paul@gmail.com <mailto:noble.paul@gmail.com>> wrote:
>> We should deprecate that feature and remove restlet dependency altogether
>>
>> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein <joelsolr@gmail.com <mailto:joelsolr@gmail.com>> wrote:
>> >
>> > Restlet again!!!!!!!
>> >
>> >
>> >
>> > Joel Bernstein
>> > http://joelsolr.blogspot.com/ <http://joelsolr.blogspot.com/>
>> >
>> >
>> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <epugh@opensourceconnections.com <mailto:epugh@opensourceconnections.com>> wrote:
>> >>
>> >> Do we have a community blessed alternative to restlet already?
>> >>
>> >> On Sep 20, 2020, at 9:40 AM, Noble Paul <noble.paul@gmail.com <mailto:noble.paul@gmail.com>> wrote:
>> >>
>> >> Haha.
>> >>
>> >> In fact schema APIs don't use restlet. Only the managed resources use it
>> >>
>> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com>> wrote:
>> >>>
>> >>> If I were talend, I'd immediately start publishing to maven central. If I were the developer who built the schema APIs, I would never have used restlet to begin with.
>> >>>
>> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, <uwe@thetaphi.de <mailto:uwe@thetaphi.de>> wrote:
>> >>>>
>> >>>> I was thinking the same. Because GitHub does not cache the downloaded artifacts like our jenkins servers.
>> >>>>
>> >>>> It seems to run it in a new VM or container every time, so it downloads all artifacts. If I were Talend, I'd also block this.
>> >>>>
>> >>>> Uwe
>> >>>>
>> >>>> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <dawid.weiss@gmail.com <mailto:dawid.weiss@gmail.com>>:
>> >>>>>
>> >>>>> I don't think it's http/https - I believe restlet repository simply
>> >>>>> bans github servers because of excessive traffic? These URLs work for
>> >>>>> me locally...
>> >>>>>
>> >>>>> Dawid
>> >>>>>
>> >>>>> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
>> >>>>> LONDON) <cpoerschke@bloomberg.net <mailto:cpoerschke@bloomberg.net>> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>> This sounds vaguely familiar. "http works, https does not work" and https://issues.apache.org/jira/browse/SOLR-13756 <https://issues.apache.org/jira/browse/SOLR-13756> possibly related?
>> >>>>>>
>> >>>>>> From: dev@lucene.apache.org <mailto:dev@lucene.apache.org> At: 09/18/20 10:01:29
>> >>>>>> To: dev@lucene.apache.org <mailto:dev@lucene.apache.org>
>> >>>>>> Subject: Re: restlet dependencies
>> >>>>>>
>> >>>>>> I don't think it is, sadly.
>> >>>>>> https://repo1.maven.org/maven2/org/restlet <https://repo1.maven.org/maven2/org/restlet>
>> >>>>>>
>> >>>>>> The link you provided (mvnrepository) aggregates from several maven
>> >>>>>> repositories.
>> >>>>>>
>> >>>>>>
>> >>>>>> D.
>> >>>>>>
>> >>>>>> On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
>> >>>>>> <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com>> wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Sorry, afk, but I heard (*hearsay*) that restlet is also on maven central
>> >>>>>>
>> >>>>>> these days. Can we confirm and switch to that? Sorry, if that's not the case.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <dawid.weiss@gmail.com <mailto:dawid.weiss@gmail.com>> wrote:
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Just FYI: can't get PR builds on github to work recently because of this:
>> >>>>>>>>
>> >>>>>>>>> Could not resolve all files for configuration
>> >>>>>>
>> >>>>>> ':solr:core:compileClasspath'.
>> >>>>>>>>
>> >>>>>>>> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>> >>>>>>>> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>> >>>>>>>> 351 > Could not get resource
>> >>>>>>>>
>> >>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res <https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res>
>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>> >>>>>>>>
>> >>>>>>>> 352 > Could not GET
>> >>>>>>>>
>> >>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res <https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res>
>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>> >>>>>>>>
>> >>>>>>>> 353 > Connection reset
>> >>>>>>>> 354 > Could not download org.restlet-2.4.3.jar
>> >>>>>>>> (org.restlet.jee:org.restlet:2.4.3)
>> >>>>>>>> 355 > Could not get resource
>> >>>>>>>>
>> >>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j <https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j>
>> >>>>>> ar'.
>> >>>>>>>>
>> >>>>>>>> 356 > Could not GET
>> >>>>>>>>
>> >>>>>> 'https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet- <https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet->
>> >>>>>> 2.4.3.jar'.
>> >>>>>>>>
>> >>>>>>>> 357 > Connection reset
>> >>>>>>>>
>> >>>>>>>> D.
>> >>>>>>>> ________________________________
>> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
>> >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
>> >>>>>>>>
>> >>>>>> ________________________________
>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
>> >>>>>>
>> >>>>>>
>> >>>>> ________________________________
>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
>> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
>> >>>>>
>> >>>>
>> >>>> --
>> >>>> Uwe Schindler
>> >>>> Achterdiek 19, 28357 Bremen
>> >>>> https://www.thetaphi.de <https://www.thetaphi.de/>
>> >>
>> >>
>> >> _______________________
>> >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy
>> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> >> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
>> >>
>>
>>
>> --
>> -----------------------------------------------------
>> Noble Paul
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
>> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
>>
>
> _______________________
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal>
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
>
Re: restlet dependencies [ In reply to ]
Ok, so we're removing from 9 (I can do that) but what should we do about
the upcoming 8.7 release? I'm fine with deprecating, but usually an
alternative approach is suggested with the deprecation notice. For cloud
mode, we can suggest our hypothetical users of this MR API to use the
config set API but what about standalone? I can do the work in 8.7 too but
not really sure how to proceed on the standalone question ...

On Fri, Sep 25, 2020 at 12:20 AM Jan Høydahl <jan.asf@cominvent.com> wrote:

> Yea, managed resources is one of the features I’ll not miss. It seemed
> smart back then, but for some reason I don’t think people use it that much,
> and I agree it makes more sense for the user to be aware of the configset
> and update the configset.
>
> I’d appreciate a upload one file API. Ishan, you could say that you can
> upload a single file to a config set only if auth is enabled OR if the
> configset is already untrusted.
>
> Jan
>
> 25. sep. 2020 kl. 06:02 skrev Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com>:
>
> SOLR-5287 has some discussion. The changes were backed out due to security
> reasons. Anyway, Eric, Tomas & David, let us not hijack this thread on
> restlet and discuss something totally unrelated.
>
> On Fri, 25 Sep, 2020, 9:20 am Ishan Chattopadhyaya, <
> ichattopadhyaya@gmail.com> wrote:
>
>> An entire configset, when uploaded via api without security enabled, is
>> marked untrusted. When creating a collection from untrusted configset,
>> certain vulnerable components can't be initialized.
>>
>> On Fri, 25 Sep, 2020, 9:04 am David Smiley, <dsmiley@apache.org> wrote:
>>
>>> Ishan: can you be more specific please? How is it less secure or harder
>>> to secure than, say, a configSet upload (internally multiple files)?
>>>
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley
>>>
>>>
>>> On Thu, Sep 24, 2020 at 1:53 PM Ishan Chattopadhyaya <
>>> ichattopadhyaya@gmail.com> wrote:
>>>
>>>> Single file update capability is a security nightmare. Even if it can
>>>> be done, it should be supported only once authc/authz have been enabled.
>>>>
>>>> On Thu, 24 Sep, 2020, 10:16 pm Tomás Fernández Löbbe, <
>>>> tomasflobbe@gmail.com> wrote:
>>>>
>>>>> I won't step in the way of a single file update. I haven't needed it
>>>>> so far though. I usually have the configsets in a Git repo (all the
>>>>> configset together) and I have a simple bash script that essentialy what's
>>>>> described in the docs[1]: Generate the zip on the fly and upload
>>>>> (optionally set the auth too). This can become a problem with big zips, but
>>>>> then again, ZooKeeper limits the size of the configs, so far it hasn't been
>>>>> an issue for me.
>>>>>
>>>>>
>>>>> [1]
>>>>> https://lucene.apache.org/solr/guide/8_6/configsets-api.html#configsets-upload
>>>>>
>>>>> On Thu, Sep 24, 2020 at 7:13 AM Eric Pugh <
>>>>> epugh@opensourceconnections.com> wrote:
>>>>>
>>>>>> It would be great if we had a simple API for updating a file in a
>>>>>> configset that didn’t assume you were just uploading a zip file.
>>>>>>
>>>>>> As an example use case, if you use the Querqy library, you need to
>>>>>> deploy a “rules.txt” file, which in olden days just went on the filesystem
>>>>>> and you would click reload on a core. In the SolrCloud world, we do this
>>>>>> awkward “Let me stick the file in Zookeeper directly, avoiding Solr, and
>>>>>> then do a collection RELOAD” to push out the file everywhere. [1] It
>>>>>> works! But it’s just awkward.
>>>>>>
>>>>>> It’s great to know that I’ll be able to change out this awkward
>>>>>> process using these magic parameters to configSet. Even nicer would be to
>>>>>> just wrap the overwrite=true&cleanup=false and the Zip requirement into
>>>>>> something that sets those.
>>>>>>
>>>>>>
>>>>>> [1]
>>>>>> https://github.com/querqy/chorus/blob/master/smui/conf/smui2solrcloud.sh#L37
>>>>>>
>>>>>> On Sep 23, 2020, at 11:57 PM, Tomás Fernández Löbbe <
>>>>>> tomasflobbe@gmail.com> wrote:
>>>>>>
>>>>>> > Hmmm; seems the configSet API doesn't have an API to update a
>>>>>> single file! I wonder if uploading a configSet to the same name
>>>>>> effectively overwrites newly updated files but does not delete the existing
>>>>>> files?
>>>>>> I've been working on this recently. As of 8.7, the UPLOAD command
>>>>>> supports overwriting (before, an UPLOAD on an existing configset name would
>>>>>> fail with BAD_REQUEST) and you can choose to cleanup or not the extra files
>>>>>> with the "cleanup" parameter.
>>>>>> You could upload a single file if you say
>>>>>> overwrite=true&cleanup=false, but it would still need to be in a zip file
>>>>>> (and needs to be located in the right path of the zip, for example, a
>>>>>> synonyms file may be in lang/synonyms_foo.txt or something)
>>>>>>
>>>>>> On Wed, Sep 23, 2020 at 8:10 PM David Smiley <dsmiley@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>>> +1 to deprecate managed resources in lieu of easier to maintain (and
>>>>>>> more flexible) file based GET/PUT into the configset.
>>>>>>>
>>>>>>> > I don't know if 9 is too soon from a deprecation stand point
>>>>>>>
>>>>>>> IMO it's never too soon as long as there is a deprecated release.
>>>>>>> Users take their time upgrading to major versions.
>>>>>>>
>>>>>>> > How much harder are the use-cases currently covered by managed
>>>>>>> resources, if that module was removed?
>>>>>>>
>>>>>>> I believe in practice, users synchronize one-way from their DB to
>>>>>>> Solr if they have dynamic resources like this. This is true where I work.
>>>>>>> Otherwise, they would probably be using Solr as the source of truth, which
>>>>>>> doesn't seem architecturally-sound for most apps IMO. Those users
>>>>>>> (hopefully few) would have to spend some time re-engineering the approach.
>>>>>>> Given one-way sync, the transition here is pretty easy: serialize the
>>>>>>> client-managed data to the right Solr format (stopwords vs synonyms vs ...)
>>>>>>> and then a file upload to Solr/ZK and then telling Solr which collections
>>>>>>> to "reload".
>>>>>>>
>>>>>>> Hmmm; seems the configSet API doesn't have an API to update a single
>>>>>>> file! I wonder if uploading a configSet to the same name effectively
>>>>>>> overwrites newly updated files but does not delete the existing files?
>>>>>>>
>>>>>>> ~ David Smiley
>>>>>>> Apache Lucene/Solr Search Developer
>>>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Sep 23, 2020 at 10:28 AM Timothy Potter <
>>>>>>> thelabdude@gmail.com> wrote:
>>>>>>>
>>>>>>>> I agree we should deprecate the managed resources feature, it was
>>>>>>>> the first thing I was asked to build by LW nearly 7 years ago, before I was
>>>>>>>> a committer. Restlet was already in place and I built on top of that, not
>>>>>>>> sure who introduced it originally (nor do I care). Clearly from the vantage
>>>>>>>> point of looking back, JAX-RS and Jersey won the day with REST in Java but
>>>>>>>> that simply wasn't the case back then. What's important is how we move
>>>>>>>> forward vs. bestowing judgement backed by wisdom of hindsight on decisions
>>>>>>>> made many years ago.
>>>>>>>>
>>>>>>>> In the short term, does Apache have an Artifactory (or similar)
>>>>>>>> where we can host the Restlet dependencies for Github to pull them from? If
>>>>>>>> not, then we can port the code that's using Restlet over to using JAX-RS /
>>>>>>>> Jersey. Personally I'd prefer we remove Managed Resources support from 9
>>>>>>>> instead of porting the Restlet code but I don't know if 9 is too soon from
>>>>>>>> a deprecation stand point?
>>>>>>>>
>>>>>>>> Tim
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Sep 21, 2020 at 11:33 PM Noble Paul <noble.paul@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> We should deprecate that feature and remove restlet dependency
>>>>>>>>> altogether
>>>>>>>>>
>>>>>>>>> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein <
>>>>>>>>> joelsolr@gmail.com> wrote:
>>>>>>>>> >
>>>>>>>>> > Restlet again!!!!!!!
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > Joel Bernstein
>>>>>>>>> > http://joelsolr.blogspot.com/
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <
>>>>>>>>> epugh@opensourceconnections.com> wrote:
>>>>>>>>> >>
>>>>>>>>> >> Do we have a community blessed alternative to restlet already?
>>>>>>>>> >>
>>>>>>>>> >> On Sep 20, 2020, at 9:40 AM, Noble Paul <noble.paul@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>> >>
>>>>>>>>> >> Haha.
>>>>>>>>> >>
>>>>>>>>> >> In fact schema APIs don't use restlet. Only the managed
>>>>>>>>> resources use it
>>>>>>>>> >>
>>>>>>>>> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
>>>>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>>>>> >>>
>>>>>>>>> >>> If I were talend, I'd immediately start publishing to maven
>>>>>>>>> central. If I were the developer who built the schema APIs, I would never
>>>>>>>>> have used restlet to begin with.
>>>>>>>>> >>>
>>>>>>>>> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, <uwe@thetaphi.de>
>>>>>>>>> wrote:
>>>>>>>>> >>>>
>>>>>>>>> >>>> I was thinking the same. Because GitHub does not cache the
>>>>>>>>> downloaded artifacts like our jenkins servers.
>>>>>>>>> >>>>
>>>>>>>>> >>>> It seems to run it in a new VM or container every time, so it
>>>>>>>>> downloads all artifacts. If I were Talend, I'd also block this.
>>>>>>>>> >>>>
>>>>>>>>> >>>> Uwe
>>>>>>>>> >>>>
>>>>>>>>> >>>> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
>>>>>>>>> dawid.weiss@gmail.com>:
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> I don't think it's http/https - I believe restlet repository
>>>>>>>>> simply
>>>>>>>>> >>>>> bans github servers because of excessive traffic? These URLs
>>>>>>>>> work for
>>>>>>>>> >>>>> me locally...
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> Dawid
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke
>>>>>>>>> (BLOOMBERG/
>>>>>>>>> >>>>> LONDON) <cpoerschke@bloomberg.net> wrote:
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> This sounds vaguely familiar. "http works, https does not
>>>>>>>>> work" and https://issues.apache.org/jira/browse/SOLR-13756
>>>>>>>>> possibly related?
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> From: dev@lucene.apache.org At: 09/18/20 10:01:29
>>>>>>>>> >>>>>> To: dev@lucene.apache.org
>>>>>>>>> >>>>>> Subject: Re: restlet dependencies
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> I don't think it is, sadly.
>>>>>>>>> >>>>>> https://repo1.maven.org/maven2/org/restlet
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> The link you provided (mvnrepository) aggregates from
>>>>>>>>> several maven
>>>>>>>>> >>>>>> repositories.
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> D.
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
>>>>>>>>> >>>>>> <ichattopadhyaya@gmail.com> wrote:
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> Sorry, afk, but I heard (*hearsay*) that restlet is also
>>>>>>>>> on maven central
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> these days. Can we confirm and switch to that? Sorry, if
>>>>>>>>> that's not the case.
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <
>>>>>>>>> dawid.weiss@gmail.com> wrote:
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>> Just FYI: can't get PR builds on github to work recently
>>>>>>>>> because of this:
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>>> Could not resolve all files for configuration
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> ':solr:core:compileClasspath'.
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>> 350 > Could not download
>>>>>>>>> org.restlet.ext.servlet-2.4.3.jar
>>>>>>>>> >>>>>>>> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>>>>>>>>> >>>>>>>> 351 > Could not get resource
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>> '
>>>>>>>>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>>>>>>>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>> 352 > Could not GET
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>> '
>>>>>>>>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>>>>>>>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>> 353 > Connection reset
>>>>>>>>> >>>>>>>> 354 > Could not download org.restlet-2.4.3.jar
>>>>>>>>> >>>>>>>> (org.restlet.jee:org.restlet:2.4.3)
>>>>>>>>> >>>>>>>> 355 > Could not get resource
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>> '
>>>>>>>>> https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
>>>>>>>>> >>>>>> ar'.
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>> 356 > Could not GET
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>> '
>>>>>>>>> https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
>>>>>>>>> >>>>>> 2.4.3.jar'.
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>> 357 > Connection reset
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>> D.
>>>>>>>>> >>>>>>>> ________________________________
>>>>>>>>> >>>>>>>> To unsubscribe, e-mail:
>>>>>>>>> dev-unsubscribe@lucene.apache.org
>>>>>>>>> >>>>>>>> For additional commands, e-mail:
>>>>>>>>> dev-help@lucene.apache.org
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>> ________________________________
>>>>>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>>> >>>>>> For additional commands, e-mail:
>>>>>>>>> dev-help@lucene.apache.org
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>> ________________________________
>>>>>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>>> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>>> >>>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>> --
>>>>>>>>> >>>> Uwe Schindler
>>>>>>>>> >>>> Achterdiek 19, 28357 Bremen
>>>>>>>>> >>>> https://www.thetaphi.de
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> _______________________
>>>>>>>>> >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
>>>>>>>>> 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>>>>>>>>> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>>>>>>>> >> This e-mail and all contents, including attachments, is
>>>>>>>>> considered to be Company Confidential unless explicitly stated otherwise,
>>>>>>>>> regardless of whether attachments are marked as such.
>>>>>>>>> >>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> -----------------------------------------------------
>>>>>>>>> Noble Paul
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>> _______________________
>>>>>> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
>>>>>> | http://www.opensourceconnections.com | My Free/Busy
>>>>>> <http://tinyurl.com/eric-cal>
>>>>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>>>>> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>>>>>> This e-mail and all contents, including attachments, is considered to
>>>>>> be Company Confidential unless explicitly stated otherwise, regardless
>>>>>> of whether attachments are marked as such.
>>>>>>
>>>>>>
>
Re: restlet dependencies [ In reply to ]
What if we suggest that you just change the files directly using the same configset discussion we had, with caveats etc. And maybe someday we get a nicer api etc for doing this type of thing...


> On Sep 25, 2020, at 9:49 AM, Timothy Potter <thelabdude@gmail.com> wrote:
>
> Ok, so we're removing from 9 (I can do that) but what should we do about the upcoming 8.7 release? I'm fine with deprecating, but usually an alternative approach is suggested with the deprecation notice. For cloud mode, we can suggest our hypothetical users of this MR API to use the config set API but what about standalone? I can do the work in 8.7 too but not really sure how to proceed on the standalone question ...
>
> On Fri, Sep 25, 2020 at 12:20 AM Jan Høydahl <jan.asf@cominvent.com <mailto:jan.asf@cominvent.com>> wrote:
> Yea, managed resources is one of the features I’ll not miss. It seemed smart back then, but for some reason I don’t think people use it that much, and I agree it makes more sense for the user to be aware of the configset and update the configset.
>
> I’d appreciate a upload one file API. Ishan, you could say that you can upload a single file to a config set only if auth is enabled OR if the configset is already untrusted.
>
> Jan
>
>> 25. sep. 2020 kl. 06:02 skrev Ishan Chattopadhyaya <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com>>:
>>
>> SOLR-5287 has some discussion. The changes were backed out due to security reasons. Anyway, Eric, Tomas & David, let us not hijack this thread on restlet and discuss something totally unrelated.
>>
>> On Fri, 25 Sep, 2020, 9:20 am Ishan Chattopadhyaya, <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com>> wrote:
>> An entire configset, when uploaded via api without security enabled, is marked untrusted. When creating a collection from untrusted configset, certain vulnerable components can't be initialized.
>>
>> On Fri, 25 Sep, 2020, 9:04 am David Smiley, <dsmiley@apache.org <mailto:dsmiley@apache.org>> wrote:
>> Ishan: can you be more specific please? How is it less secure or harder to secure than, say, a configSet upload (internally multiple files)?
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley <http://www.linkedin.com/in/davidwsmiley>
>>
>> On Thu, Sep 24, 2020 at 1:53 PM Ishan Chattopadhyaya <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com>> wrote:
>> Single file update capability is a security nightmare. Even if it can be done, it should be supported only once authc/authz have been enabled.
>>
>> On Thu, 24 Sep, 2020, 10:16 pm Tomás Fernández Löbbe, <tomasflobbe@gmail.com <mailto:tomasflobbe@gmail.com>> wrote:
>> I won't step in the way of a single file update. I haven't needed it so far though. I usually have the configsets in a Git repo (all the configset together) and I have a simple bash script that essentialy what's described in the docs[1]: Generate the zip on the fly and upload (optionally set the auth too). This can become a problem with big zips, but then again, ZooKeeper limits the size of the configs, so far it hasn't been an issue for me.
>>
>>
>> [1] https://lucene.apache.org/solr/guide/8_6/configsets-api.html#configsets-upload <https://lucene.apache.org/solr/guide/8_6/configsets-api.html#configsets-upload>
>> On Thu, Sep 24, 2020 at 7:13 AM Eric Pugh <epugh@opensourceconnections.com <mailto:epugh@opensourceconnections.com>> wrote:
>> It would be great if we had a simple API for updating a file in a configset that didn’t assume you were just uploading a zip file.
>>
>> As an example use case, if you use the Querqy library, you need to deploy a “rules.txt” file, which in olden days just went on the filesystem and you would click reload on a core. In the SolrCloud world, we do this awkward “Let me stick the file in Zookeeper directly, avoiding Solr, and then do a collection RELOAD” to push out the file everywhere. [1] It works! But it’s just awkward.
>>
>> It’s great to know that I’ll be able to change out this awkward process using these magic parameters to configSet. Even nicer would be to just wrap the overwrite=true&cleanup=false and the Zip requirement into something that sets those.
>>
>>
>> [1] https://github.com/querqy/chorus/blob/master/smui/conf/smui2solrcloud.sh#L37 <https://github.com/querqy/chorus/blob/master/smui/conf/smui2solrcloud.sh#L37>
>>
>>> On Sep 23, 2020, at 11:57 PM, Tomás Fernández Löbbe <tomasflobbe@gmail.com <mailto:tomasflobbe@gmail.com>> wrote:
>>>
>>> > Hmmm; seems the configSet API doesn't have an API to update a single file! I wonder if uploading a configSet to the same name effectively overwrites newly updated files but does not delete the existing files?
>>> I've been working on this recently. As of 8.7, the UPLOAD command supports overwriting (before, an UPLOAD on an existing configset name would fail with BAD_REQUEST) and you can choose to cleanup or not the extra files with the "cleanup" parameter.
>>> You could upload a single file if you say overwrite=true&cleanup=false, but it would still need to be in a zip file (and needs to be located in the right path of the zip, for example, a synonyms file may be in lang/synonyms_foo.txt or something)
>>>
>>> On Wed, Sep 23, 2020 at 8:10 PM David Smiley <dsmiley@apache.org <mailto:dsmiley@apache.org>> wrote:
>>> +1 to deprecate managed resources in lieu of easier to maintain (and more flexible) file based GET/PUT into the configset.
>>>
>>> > I don't know if 9 is too soon from a deprecation stand point
>>>
>>> IMO it's never too soon as long as there is a deprecated release. Users take their time upgrading to major versions.
>>>
>>> > How much harder are the use-cases currently covered by managed resources, if that module was removed?
>>>
>>> I believe in practice, users synchronize one-way from their DB to Solr if they have dynamic resources like this. This is true where I work. Otherwise, they would probably be using Solr as the source of truth, which doesn't seem architecturally-sound for most apps IMO. Those users (hopefully few) would have to spend some time re-engineering the approach. Given one-way sync, the transition here is pretty easy: serialize the client-managed data to the right Solr format (stopwords vs synonyms vs ...) and then a file upload to Solr/ZK and then telling Solr which collections to "reload".
>>>
>>> Hmmm; seems the configSet API doesn't have an API to update a single file! I wonder if uploading a configSet to the same name effectively overwrites newly updated files but does not delete the existing files?
>>>
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley <http://www.linkedin.com/in/davidwsmiley>
>>>
>>> On Wed, Sep 23, 2020 at 10:28 AM Timothy Potter <thelabdude@gmail.com <mailto:thelabdude@gmail.com>> wrote:
>>> I agree we should deprecate the managed resources feature, it was the first thing I was asked to build by LW nearly 7 years ago, before I was a committer. Restlet was already in place and I built on top of that, not sure who introduced it originally (nor do I care). Clearly from the vantage point of looking back, JAX-RS and Jersey won the day with REST in Java but that simply wasn't the case back then. What's important is how we move forward vs. bestowing judgement backed by wisdom of hindsight on decisions made many years ago.
>>>
>>> In the short term, does Apache have an Artifactory (or similar) where we can host the Restlet dependencies for Github to pull them from? If not, then we can port the code that's using Restlet over to using JAX-RS / Jersey. Personally I'd prefer we remove Managed Resources support from 9 instead of porting the Restlet code but I don't know if 9 is too soon from a deprecation stand point?
>>>
>>> Tim
>>>
>>>
>>> On Mon, Sep 21, 2020 at 11:33 PM Noble Paul <noble.paul@gmail.com <mailto:noble.paul@gmail.com>> wrote:
>>> We should deprecate that feature and remove restlet dependency altogether
>>>
>>> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein <joelsolr@gmail.com <mailto:joelsolr@gmail.com>> wrote:
>>> >
>>> > Restlet again!!!!!!!
>>> >
>>> >
>>> >
>>> > Joel Bernstein
>>> > http://joelsolr.blogspot.com/ <http://joelsolr.blogspot.com/>
>>> >
>>> >
>>> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <epugh@opensourceconnections.com <mailto:epugh@opensourceconnections.com>> wrote:
>>> >>
>>> >> Do we have a community blessed alternative to restlet already?
>>> >>
>>> >> On Sep 20, 2020, at 9:40 AM, Noble Paul <noble.paul@gmail.com <mailto:noble.paul@gmail.com>> wrote:
>>> >>
>>> >> Haha.
>>> >>
>>> >> In fact schema APIs don't use restlet. Only the managed resources use it
>>> >>
>>> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com>> wrote:
>>> >>>
>>> >>> If I were talend, I'd immediately start publishing to maven central. If I were the developer who built the schema APIs, I would never have used restlet to begin with.
>>> >>>
>>> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, <uwe@thetaphi.de <mailto:uwe@thetaphi.de>> wrote:
>>> >>>>
>>> >>>> I was thinking the same. Because GitHub does not cache the downloaded artifacts like our jenkins servers.
>>> >>>>
>>> >>>> It seems to run it in a new VM or container every time, so it downloads all artifacts. If I were Talend, I'd also block this.
>>> >>>>
>>> >>>> Uwe
>>> >>>>
>>> >>>> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <dawid.weiss@gmail.com <mailto:dawid.weiss@gmail.com>>:
>>> >>>>>
>>> >>>>> I don't think it's http/https - I believe restlet repository simply
>>> >>>>> bans github servers because of excessive traffic? These URLs work for
>>> >>>>> me locally...
>>> >>>>>
>>> >>>>> Dawid
>>> >>>>>
>>> >>>>> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
>>> >>>>> LONDON) <cpoerschke@bloomberg.net <mailto:cpoerschke@bloomberg.net>> wrote:
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> This sounds vaguely familiar. "http works, https does not work" and https://issues.apache.org/jira/browse/SOLR-13756 <https://issues.apache.org/jira/browse/SOLR-13756> possibly related?
>>> >>>>>>
>>> >>>>>> From: dev@lucene.apache.org <mailto:dev@lucene.apache.org> At: 09/18/20 10:01:29
>>> >>>>>> To: dev@lucene.apache.org <mailto:dev@lucene.apache.org>
>>> >>>>>> Subject: Re: restlet dependencies
>>> >>>>>>
>>> >>>>>> I don't think it is, sadly.
>>> >>>>>> https://repo1.maven.org/maven2/org/restlet <https://repo1.maven.org/maven2/org/restlet>
>>> >>>>>>
>>> >>>>>> The link you provided (mvnrepository) aggregates from several maven
>>> >>>>>> repositories.
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> D.
>>> >>>>>>
>>> >>>>>> On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
>>> >>>>>> <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com>> wrote:
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> Sorry, afk, but I heard (*hearsay*) that restlet is also on maven central
>>> >>>>>>
>>> >>>>>> these days. Can we confirm and switch to that? Sorry, if that's not the case.
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <dawid.weiss@gmail.com <mailto:dawid.weiss@gmail.com>> wrote:
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> Just FYI: can't get PR builds on github to work recently because of this:
>>> >>>>>>>>
>>> >>>>>>>>> Could not resolve all files for configuration
>>> >>>>>>
>>> >>>>>> ':solr:core:compileClasspath'.
>>> >>>>>>>>
>>> >>>>>>>> 350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>>> >>>>>>>> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>>> >>>>>>>> 351 > Could not get resource
>>> >>>>>>>>
>>> >>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res <https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res>
>>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>>> >>>>>>>>
>>> >>>>>>>> 352 > Could not GET
>>> >>>>>>>>
>>> >>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res <https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res>
>>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>>> >>>>>>>>
>>> >>>>>>>> 353 > Connection reset
>>> >>>>>>>> 354 > Could not download org.restlet-2.4.3.jar
>>> >>>>>>>> (org.restlet.jee:org.restlet:2.4.3)
>>> >>>>>>>> 355 > Could not get resource
>>> >>>>>>>>
>>> >>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j <https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j>
>>> >>>>>> ar'.
>>> >>>>>>>>
>>> >>>>>>>> 356 > Could not GET
>>> >>>>>>>>
>>> >>>>>> 'https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet- <https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet->
>>> >>>>>> 2.4.3.jar'.
>>> >>>>>>>>
>>> >>>>>>>> 357 > Connection reset
>>> >>>>>>>>
>>> >>>>>>>> D.
>>> >>>>>>>> ________________________________
>>> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
>>> >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
>>> >>>>>>>>
>>> >>>>>> ________________________________
>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
>>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
>>> >>>>>>
>>> >>>>>>
>>> >>>>> ________________________________
>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
>>> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
>>> >>>>>
>>> >>>>
>>> >>>> --
>>> >>>> Uwe Schindler
>>> >>>> Achterdiek 19, 28357 Bremen
>>> >>>> https://www.thetaphi.de <https://www.thetaphi.de/>
>>> >>
>>> >>
>>> >> _______________________
>>> >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy
>>> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>> >> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
>>> >>
>>>
>>>
>>> --
>>> -----------------------------------------------------
>>> Noble Paul
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
>>> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
>>>
>>
>> _______________________
>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal>
>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
>>
>

_______________________
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal>
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
Re: restlet dependencies [ In reply to ]
I think it can simply be a limitation of standalone. If you want something
similar to managed-resources, use SolrCloud.
I want to get to this for 8.7, maybe this weekend,
https://issues.apache.org/jira/browse/SOLR-12987 which can be used to help
inform users of deprecations.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Fri, Sep 25, 2020 at 9:49 AM Timothy Potter <thelabdude@gmail.com> wrote:

> Ok, so we're removing from 9 (I can do that) but what should we do about
> the upcoming 8.7 release? I'm fine with deprecating, but usually an
> alternative approach is suggested with the deprecation notice. For cloud
> mode, we can suggest our hypothetical users of this MR API to use the
> config set API but what about standalone? I can do the work in 8.7 too but
> not really sure how to proceed on the standalone question ...
>
> On Fri, Sep 25, 2020 at 12:20 AM Jan Høydahl <jan.asf@cominvent.com>
> wrote:
>
>> Yea, managed resources is one of the features I’ll not miss. It seemed
>> smart back then, but for some reason I don’t think people use it that much,
>> and I agree it makes more sense for the user to be aware of the configset
>> and update the configset.
>>
>> I’d appreciate a upload one file API. Ishan, you could say that you can
>> upload a single file to a config set only if auth is enabled OR if the
>> configset is already untrusted.
>>
>> Jan
>>
>> 25. sep. 2020 kl. 06:02 skrev Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com>:
>>
>> SOLR-5287 has some discussion. The changes were backed out due to
>> security reasons. Anyway, Eric, Tomas & David, let us not hijack this
>> thread on restlet and discuss something totally unrelated.
>>
>> On Fri, 25 Sep, 2020, 9:20 am Ishan Chattopadhyaya, <
>> ichattopadhyaya@gmail.com> wrote:
>>
>>> An entire configset, when uploaded via api without security enabled, is
>>> marked untrusted. When creating a collection from untrusted configset,
>>> certain vulnerable components can't be initialized.
>>>
>>> On Fri, 25 Sep, 2020, 9:04 am David Smiley, <dsmiley@apache.org> wrote:
>>>
>>>> Ishan: can you be more specific please? How is it less secure or
>>>> harder to secure than, say, a configSet upload (internally multiple files)?
>>>>
>>>> ~ David Smiley
>>>> Apache Lucene/Solr Search Developer
>>>> http://www.linkedin.com/in/davidwsmiley
>>>>
>>>>
>>>> On Thu, Sep 24, 2020 at 1:53 PM Ishan Chattopadhyaya <
>>>> ichattopadhyaya@gmail.com> wrote:
>>>>
>>>>> Single file update capability is a security nightmare. Even if it can
>>>>> be done, it should be supported only once authc/authz have been enabled.
>>>>>
>>>>> On Thu, 24 Sep, 2020, 10:16 pm Tomás Fernández Löbbe, <
>>>>> tomasflobbe@gmail.com> wrote:
>>>>>
>>>>>> I won't step in the way of a single file update. I haven't needed it
>>>>>> so far though. I usually have the configsets in a Git repo (all the
>>>>>> configset together) and I have a simple bash script that essentialy what's
>>>>>> described in the docs[1]: Generate the zip on the fly and upload
>>>>>> (optionally set the auth too). This can become a problem with big zips, but
>>>>>> then again, ZooKeeper limits the size of the configs, so far it hasn't been
>>>>>> an issue for me.
>>>>>>
>>>>>>
>>>>>> [1]
>>>>>> https://lucene.apache.org/solr/guide/8_6/configsets-api.html#configsets-upload
>>>>>>
>>>>>> On Thu, Sep 24, 2020 at 7:13 AM Eric Pugh <
>>>>>> epugh@opensourceconnections.com> wrote:
>>>>>>
>>>>>>> It would be great if we had a simple API for updating a file in a
>>>>>>> configset that didn’t assume you were just uploading a zip file.
>>>>>>>
>>>>>>> As an example use case, if you use the Querqy library, you need to
>>>>>>> deploy a “rules.txt” file, which in olden days just went on the filesystem
>>>>>>> and you would click reload on a core. In the SolrCloud world, we do this
>>>>>>> awkward “Let me stick the file in Zookeeper directly, avoiding Solr, and
>>>>>>> then do a collection RELOAD” to push out the file everywhere. [1] It
>>>>>>> works! But it’s just awkward.
>>>>>>>
>>>>>>> It’s great to know that I’ll be able to change out this awkward
>>>>>>> process using these magic parameters to configSet. Even nicer would be to
>>>>>>> just wrap the overwrite=true&cleanup=false and the Zip requirement into
>>>>>>> something that sets those.
>>>>>>>
>>>>>>>
>>>>>>> [1]
>>>>>>> https://github.com/querqy/chorus/blob/master/smui/conf/smui2solrcloud.sh#L37
>>>>>>>
>>>>>>> On Sep 23, 2020, at 11:57 PM, Tomás Fernández Löbbe <
>>>>>>> tomasflobbe@gmail.com> wrote:
>>>>>>>
>>>>>>> > Hmmm; seems the configSet API doesn't have an API to update a
>>>>>>> single file! I wonder if uploading a configSet to the same name
>>>>>>> effectively overwrites newly updated files but does not delete the existing
>>>>>>> files?
>>>>>>> I've been working on this recently. As of 8.7, the UPLOAD command
>>>>>>> supports overwriting (before, an UPLOAD on an existing configset name would
>>>>>>> fail with BAD_REQUEST) and you can choose to cleanup or not the extra files
>>>>>>> with the "cleanup" parameter.
>>>>>>> You could upload a single file if you say
>>>>>>> overwrite=true&cleanup=false, but it would still need to be in a zip file
>>>>>>> (and needs to be located in the right path of the zip, for example, a
>>>>>>> synonyms file may be in lang/synonyms_foo.txt or something)
>>>>>>>
>>>>>>> On Wed, Sep 23, 2020 at 8:10 PM David Smiley <dsmiley@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> +1 to deprecate managed resources in lieu of easier to maintain
>>>>>>>> (and more flexible) file based GET/PUT into the configset.
>>>>>>>>
>>>>>>>> > I don't know if 9 is too soon from a deprecation stand point
>>>>>>>>
>>>>>>>> IMO it's never too soon as long as there is a deprecated release.
>>>>>>>> Users take their time upgrading to major versions.
>>>>>>>>
>>>>>>>> > How much harder are the use-cases currently covered by managed
>>>>>>>> resources, if that module was removed?
>>>>>>>>
>>>>>>>> I believe in practice, users synchronize one-way from their DB to
>>>>>>>> Solr if they have dynamic resources like this. This is true where I work.
>>>>>>>> Otherwise, they would probably be using Solr as the source of truth, which
>>>>>>>> doesn't seem architecturally-sound for most apps IMO. Those users
>>>>>>>> (hopefully few) would have to spend some time re-engineering the approach.
>>>>>>>> Given one-way sync, the transition here is pretty easy: serialize the
>>>>>>>> client-managed data to the right Solr format (stopwords vs synonyms vs ...)
>>>>>>>> and then a file upload to Solr/ZK and then telling Solr which collections
>>>>>>>> to "reload".
>>>>>>>>
>>>>>>>> Hmmm; seems the configSet API doesn't have an API to update a
>>>>>>>> single file! I wonder if uploading a configSet to the same name
>>>>>>>> effectively overwrites newly updated files but does not delete the existing
>>>>>>>> files?
>>>>>>>>
>>>>>>>> ~ David Smiley
>>>>>>>> Apache Lucene/Solr Search Developer
>>>>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Sep 23, 2020 at 10:28 AM Timothy Potter <
>>>>>>>> thelabdude@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> I agree we should deprecate the managed resources feature, it was
>>>>>>>>> the first thing I was asked to build by LW nearly 7 years ago, before I was
>>>>>>>>> a committer. Restlet was already in place and I built on top of that, not
>>>>>>>>> sure who introduced it originally (nor do I care). Clearly from the vantage
>>>>>>>>> point of looking back, JAX-RS and Jersey won the day with REST in Java but
>>>>>>>>> that simply wasn't the case back then. What's important is how we move
>>>>>>>>> forward vs. bestowing judgement backed by wisdom of hindsight on decisions
>>>>>>>>> made many years ago.
>>>>>>>>>
>>>>>>>>> In the short term, does Apache have an Artifactory (or similar)
>>>>>>>>> where we can host the Restlet dependencies for Github to pull them from? If
>>>>>>>>> not, then we can port the code that's using Restlet over to using JAX-RS /
>>>>>>>>> Jersey. Personally I'd prefer we remove Managed Resources support from 9
>>>>>>>>> instead of porting the Restlet code but I don't know if 9 is too soon from
>>>>>>>>> a deprecation stand point?
>>>>>>>>>
>>>>>>>>> Tim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Sep 21, 2020 at 11:33 PM Noble Paul <noble.paul@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> We should deprecate that feature and remove restlet dependency
>>>>>>>>>> altogether
>>>>>>>>>>
>>>>>>>>>> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein <
>>>>>>>>>> joelsolr@gmail.com> wrote:
>>>>>>>>>> >
>>>>>>>>>> > Restlet again!!!!!!!
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > Joel Bernstein
>>>>>>>>>> > http://joelsolr.blogspot.com/
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <
>>>>>>>>>> epugh@opensourceconnections.com> wrote:
>>>>>>>>>> >>
>>>>>>>>>> >> Do we have a community blessed alternative to restlet already?
>>>>>>>>>> >>
>>>>>>>>>> >> On Sep 20, 2020, at 9:40 AM, Noble Paul <noble.paul@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>> >>
>>>>>>>>>> >> Haha.
>>>>>>>>>> >>
>>>>>>>>>> >> In fact schema APIs don't use restlet. Only the managed
>>>>>>>>>> resources use it
>>>>>>>>>> >>
>>>>>>>>>> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
>>>>>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>>>>>> >>>
>>>>>>>>>> >>> If I were talend, I'd immediately start publishing to maven
>>>>>>>>>> central. If I were the developer who built the schema APIs, I would never
>>>>>>>>>> have used restlet to begin with.
>>>>>>>>>> >>>
>>>>>>>>>> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, <uwe@thetaphi.de>
>>>>>>>>>> wrote:
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> I was thinking the same. Because GitHub does not cache the
>>>>>>>>>> downloaded artifacts like our jenkins servers.
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> It seems to run it in a new VM or container every time, so
>>>>>>>>>> it downloads all artifacts. If I were Talend, I'd also block this.
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> Uwe
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
>>>>>>>>>> dawid.weiss@gmail.com>:
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> I don't think it's http/https - I believe restlet
>>>>>>>>>> repository simply
>>>>>>>>>> >>>>> bans github servers because of excessive traffic? These
>>>>>>>>>> URLs work for
>>>>>>>>>> >>>>> me locally...
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> Dawid
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke
>>>>>>>>>> (BLOOMBERG/
>>>>>>>>>> >>>>> LONDON) <cpoerschke@bloomberg.net> wrote:
>>>>>>>>>> >>>>>>
>>>>>>>>>> >>>>>>
>>>>>>>>>> >>>>>> This sounds vaguely familiar. "http works, https does not
>>>>>>>>>> work" and https://issues.apache.org/jira/browse/SOLR-13756
>>>>>>>>>> possibly related?
>>>>>>>>>> >>>>>>
>>>>>>>>>> >>>>>> From: dev@lucene.apache.org At: 09/18/20 10:01:29
>>>>>>>>>> >>>>>> To: dev@lucene.apache.org
>>>>>>>>>> >>>>>> Subject: Re: restlet dependencies
>>>>>>>>>> >>>>>>
>>>>>>>>>> >>>>>> I don't think it is, sadly.
>>>>>>>>>> >>>>>> https://repo1.maven.org/maven2/org/restlet
>>>>>>>>>> >>>>>>
>>>>>>>>>> >>>>>> The link you provided (mvnrepository) aggregates from
>>>>>>>>>> several maven
>>>>>>>>>> >>>>>> repositories.
>>>>>>>>>> >>>>>>
>>>>>>>>>> >>>>>>
>>>>>>>>>> >>>>>> D.
>>>>>>>>>> >>>>>>
>>>>>>>>>> >>>>>> On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
>>>>>>>>>> >>>>>> <ichattopadhyaya@gmail.com> wrote:
>>>>>>>>>> >>>>>>>
>>>>>>>>>> >>>>>>>
>>>>>>>>>> >>>>>>> Sorry, afk, but I heard (*hearsay*) that restlet is also
>>>>>>>>>> on maven central
>>>>>>>>>> >>>>>>
>>>>>>>>>> >>>>>> these days. Can we confirm and switch to that? Sorry, if
>>>>>>>>>> that's not the case.
>>>>>>>>>> >>>>>>>
>>>>>>>>>> >>>>>>>
>>>>>>>>>> >>>>>>> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <
>>>>>>>>>> dawid.weiss@gmail.com> wrote:
>>>>>>>>>> >>>>>>>>
>>>>>>>>>> >>>>>>>>
>>>>>>>>>> >>>>>>>> Just FYI: can't get PR builds on github to work
>>>>>>>>>> recently because of this:
>>>>>>>>>> >>>>>>>>
>>>>>>>>>> >>>>>>>>> Could not resolve all files for configuration
>>>>>>>>>> >>>>>>
>>>>>>>>>> >>>>>> ':solr:core:compileClasspath'.
>>>>>>>>>> >>>>>>>>
>>>>>>>>>> >>>>>>>> 350 > Could not download
>>>>>>>>>> org.restlet.ext.servlet-2.4.3.jar
>>>>>>>>>> >>>>>>>> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>>>>>>>>>> >>>>>>>> 351 > Could not get resource
>>>>>>>>>> >>>>>>>>
>>>>>>>>>> >>>>>> '
>>>>>>>>>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>>>>>>>>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>>>>>>>>>> >>>>>>>>
>>>>>>>>>> >>>>>>>> 352 > Could not GET
>>>>>>>>>> >>>>>>>>
>>>>>>>>>> >>>>>> '
>>>>>>>>>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>>>>>>>>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>>>>>>>>>> >>>>>>>>
>>>>>>>>>> >>>>>>>> 353 > Connection reset
>>>>>>>>>> >>>>>>>> 354 > Could not download org.restlet-2.4.3.jar
>>>>>>>>>> >>>>>>>> (org.restlet.jee:org.restlet:2.4.3)
>>>>>>>>>> >>>>>>>> 355 > Could not get resource
>>>>>>>>>> >>>>>>>>
>>>>>>>>>> >>>>>> '
>>>>>>>>>> https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
>>>>>>>>>> >>>>>> ar'.
>>>>>>>>>> >>>>>>>>
>>>>>>>>>> >>>>>>>> 356 > Could not GET
>>>>>>>>>> >>>>>>>>
>>>>>>>>>> >>>>>> '
>>>>>>>>>> https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
>>>>>>>>>> >>>>>> 2.4.3.jar'.
>>>>>>>>>> >>>>>>>>
>>>>>>>>>> >>>>>>>> 357 > Connection reset
>>>>>>>>>> >>>>>>>>
>>>>>>>>>> >>>>>>>> D.
>>>>>>>>>> >>>>>>>> ________________________________
>>>>>>>>>> >>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>> dev-unsubscribe@lucene.apache.org
>>>>>>>>>> >>>>>>>> For additional commands, e-mail:
>>>>>>>>>> dev-help@lucene.apache.org
>>>>>>>>>> >>>>>>>>
>>>>>>>>>> >>>>>> ________________________________
>>>>>>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>>>> >>>>>> For additional commands, e-mail:
>>>>>>>>>> dev-help@lucene.apache.org
>>>>>>>>>> >>>>>>
>>>>>>>>>> >>>>>>
>>>>>>>>>> >>>>> ________________________________
>>>>>>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>>>> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> --
>>>>>>>>>> >>>> Uwe Schindler
>>>>>>>>>> >>>> Achterdiek 19, 28357 Bremen
>>>>>>>>>> >>>> https://www.thetaphi.de
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >> _______________________
>>>>>>>>>> >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
>>>>>>>>>> 434.466.1467 | http://www.opensourceconnections.com | My
>>>>>>>>>> Free/Busy
>>>>>>>>>> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>>>>>>>>> >> This e-mail and all contents, including attachments, is
>>>>>>>>>> considered to be Company Confidential unless explicitly stated otherwise,
>>>>>>>>>> regardless of whether attachments are marked as such.
>>>>>>>>>> >>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> -----------------------------------------------------
>>>>>>>>>> Noble Paul
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> _______________________
>>>>>>> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
>>>>>>> | http://www.opensourceconnections.com | My Free/Busy
>>>>>>> <http://tinyurl.com/eric-cal>
>>>>>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>>>>>> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>>>>>>> This e-mail and all contents, including attachments, is considered
>>>>>>> to be Company Confidential unless explicitly stated otherwise, regardless
>>>>>>> of whether attachments are marked as such.
>>>>>>>
>>>>>>>
>>
Re: restlet dependencies [ In reply to ]
I've occasionally also seen connections reset with Lucene on Maven Central
and I've been pointed to https://github.com/gradle/gradle/pull/13144 by one
of our build engineers at Elastic. So maybe we also need to upgrade to
Gradle 6.6.1?

On Fri, Sep 25, 2020 at 4:50 PM David Smiley <dsmiley@apache.org> wrote:

> I think it can simply be a limitation of standalone. If you want
> something similar to managed-resources, use SolrCloud.
> I want to get to this for 8.7, maybe this weekend,
> https://issues.apache.org/jira/browse/SOLR-12987 which can be used to
> help inform users of deprecations.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Fri, Sep 25, 2020 at 9:49 AM Timothy Potter <thelabdude@gmail.com>
> wrote:
>
>> Ok, so we're removing from 9 (I can do that) but what should we do about
>> the upcoming 8.7 release? I'm fine with deprecating, but usually an
>> alternative approach is suggested with the deprecation notice. For cloud
>> mode, we can suggest our hypothetical users of this MR API to use the
>> config set API but what about standalone? I can do the work in 8.7 too but
>> not really sure how to proceed on the standalone question ...
>>
>> On Fri, Sep 25, 2020 at 12:20 AM Jan Høydahl <jan.asf@cominvent.com>
>> wrote:
>>
>>> Yea, managed resources is one of the features I’ll not miss. It seemed
>>> smart back then, but for some reason I don’t think people use it that much,
>>> and I agree it makes more sense for the user to be aware of the configset
>>> and update the configset.
>>>
>>> I’d appreciate a upload one file API. Ishan, you could say that you can
>>> upload a single file to a config set only if auth is enabled OR if the
>>> configset is already untrusted.
>>>
>>> Jan
>>>
>>> 25. sep. 2020 kl. 06:02 skrev Ishan Chattopadhyaya <
>>> ichattopadhyaya@gmail.com>:
>>>
>>> SOLR-5287 has some discussion. The changes were backed out due to
>>> security reasons. Anyway, Eric, Tomas & David, let us not hijack this
>>> thread on restlet and discuss something totally unrelated.
>>>
>>> On Fri, 25 Sep, 2020, 9:20 am Ishan Chattopadhyaya, <
>>> ichattopadhyaya@gmail.com> wrote:
>>>
>>>> An entire configset, when uploaded via api without security enabled, is
>>>> marked untrusted. When creating a collection from untrusted configset,
>>>> certain vulnerable components can't be initialized.
>>>>
>>>> On Fri, 25 Sep, 2020, 9:04 am David Smiley, <dsmiley@apache.org> wrote:
>>>>
>>>>> Ishan: can you be more specific please? How is it less secure or
>>>>> harder to secure than, say, a configSet upload (internally multiple files)?
>>>>>
>>>>> ~ David Smiley
>>>>> Apache Lucene/Solr Search Developer
>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>
>>>>>
>>>>> On Thu, Sep 24, 2020 at 1:53 PM Ishan Chattopadhyaya <
>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>
>>>>>> Single file update capability is a security nightmare. Even if it can
>>>>>> be done, it should be supported only once authc/authz have been enabled.
>>>>>>
>>>>>> On Thu, 24 Sep, 2020, 10:16 pm Tomás Fernández Löbbe, <
>>>>>> tomasflobbe@gmail.com> wrote:
>>>>>>
>>>>>>> I won't step in the way of a single file update. I haven't needed it
>>>>>>> so far though. I usually have the configsets in a Git repo (all the
>>>>>>> configset together) and I have a simple bash script that essentialy what's
>>>>>>> described in the docs[1]: Generate the zip on the fly and upload
>>>>>>> (optionally set the auth too). This can become a problem with big zips, but
>>>>>>> then again, ZooKeeper limits the size of the configs, so far it hasn't been
>>>>>>> an issue for me.
>>>>>>>
>>>>>>>
>>>>>>> [1]
>>>>>>> https://lucene.apache.org/solr/guide/8_6/configsets-api.html#configsets-upload
>>>>>>>
>>>>>>> On Thu, Sep 24, 2020 at 7:13 AM Eric Pugh <
>>>>>>> epugh@opensourceconnections.com> wrote:
>>>>>>>
>>>>>>>> It would be great if we had a simple API for updating a file in a
>>>>>>>> configset that didn’t assume you were just uploading a zip file.
>>>>>>>>
>>>>>>>> As an example use case, if you use the Querqy library, you need to
>>>>>>>> deploy a “rules.txt” file, which in olden days just went on the filesystem
>>>>>>>> and you would click reload on a core. In the SolrCloud world, we do this
>>>>>>>> awkward “Let me stick the file in Zookeeper directly, avoiding Solr, and
>>>>>>>> then do a collection RELOAD” to push out the file everywhere. [1] It
>>>>>>>> works! But it’s just awkward.
>>>>>>>>
>>>>>>>> It’s great to know that I’ll be able to change out this awkward
>>>>>>>> process using these magic parameters to configSet. Even nicer would be to
>>>>>>>> just wrap the overwrite=true&cleanup=false and the Zip requirement into
>>>>>>>> something that sets those.
>>>>>>>>
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://github.com/querqy/chorus/blob/master/smui/conf/smui2solrcloud.sh#L37
>>>>>>>>
>>>>>>>> On Sep 23, 2020, at 11:57 PM, Tomás Fernández Löbbe <
>>>>>>>> tomasflobbe@gmail.com> wrote:
>>>>>>>>
>>>>>>>> > Hmmm; seems the configSet API doesn't have an API to update a
>>>>>>>> single file! I wonder if uploading a configSet to the same name
>>>>>>>> effectively overwrites newly updated files but does not delete the existing
>>>>>>>> files?
>>>>>>>> I've been working on this recently. As of 8.7, the UPLOAD command
>>>>>>>> supports overwriting (before, an UPLOAD on an existing configset name would
>>>>>>>> fail with BAD_REQUEST) and you can choose to cleanup or not the extra files
>>>>>>>> with the "cleanup" parameter.
>>>>>>>> You could upload a single file if you say
>>>>>>>> overwrite=true&cleanup=false, but it would still need to be in a zip file
>>>>>>>> (and needs to be located in the right path of the zip, for example, a
>>>>>>>> synonyms file may be in lang/synonyms_foo.txt or something)
>>>>>>>>
>>>>>>>> On Wed, Sep 23, 2020 at 8:10 PM David Smiley <dsmiley@apache.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> +1 to deprecate managed resources in lieu of easier to maintain
>>>>>>>>> (and more flexible) file based GET/PUT into the configset.
>>>>>>>>>
>>>>>>>>> > I don't know if 9 is too soon from a deprecation stand point
>>>>>>>>>
>>>>>>>>> IMO it's never too soon as long as there is a deprecated release.
>>>>>>>>> Users take their time upgrading to major versions.
>>>>>>>>>
>>>>>>>>> > How much harder are the use-cases currently covered by managed
>>>>>>>>> resources, if that module was removed?
>>>>>>>>>
>>>>>>>>> I believe in practice, users synchronize one-way from their DB to
>>>>>>>>> Solr if they have dynamic resources like this. This is true where I work.
>>>>>>>>> Otherwise, they would probably be using Solr as the source of truth, which
>>>>>>>>> doesn't seem architecturally-sound for most apps IMO. Those users
>>>>>>>>> (hopefully few) would have to spend some time re-engineering the approach.
>>>>>>>>> Given one-way sync, the transition here is pretty easy: serialize the
>>>>>>>>> client-managed data to the right Solr format (stopwords vs synonyms vs ...)
>>>>>>>>> and then a file upload to Solr/ZK and then telling Solr which collections
>>>>>>>>> to "reload".
>>>>>>>>>
>>>>>>>>> Hmmm; seems the configSet API doesn't have an API to update a
>>>>>>>>> single file! I wonder if uploading a configSet to the same name
>>>>>>>>> effectively overwrites newly updated files but does not delete the existing
>>>>>>>>> files?
>>>>>>>>>
>>>>>>>>> ~ David Smiley
>>>>>>>>> Apache Lucene/Solr Search Developer
>>>>>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Sep 23, 2020 at 10:28 AM Timothy Potter <
>>>>>>>>> thelabdude@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> I agree we should deprecate the managed resources feature, it was
>>>>>>>>>> the first thing I was asked to build by LW nearly 7 years ago, before I was
>>>>>>>>>> a committer. Restlet was already in place and I built on top of that, not
>>>>>>>>>> sure who introduced it originally (nor do I care). Clearly from the vantage
>>>>>>>>>> point of looking back, JAX-RS and Jersey won the day with REST in Java but
>>>>>>>>>> that simply wasn't the case back then. What's important is how we move
>>>>>>>>>> forward vs. bestowing judgement backed by wisdom of hindsight on decisions
>>>>>>>>>> made many years ago.
>>>>>>>>>>
>>>>>>>>>> In the short term, does Apache have an Artifactory (or similar)
>>>>>>>>>> where we can host the Restlet dependencies for Github to pull them from? If
>>>>>>>>>> not, then we can port the code that's using Restlet over to using JAX-RS /
>>>>>>>>>> Jersey. Personally I'd prefer we remove Managed Resources support from 9
>>>>>>>>>> instead of porting the Restlet code but I don't know if 9 is too soon from
>>>>>>>>>> a deprecation stand point?
>>>>>>>>>>
>>>>>>>>>> Tim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Sep 21, 2020 at 11:33 PM Noble Paul <noble.paul@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> We should deprecate that feature and remove restlet dependency
>>>>>>>>>>> altogether
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein <
>>>>>>>>>>> joelsolr@gmail.com> wrote:
>>>>>>>>>>> >
>>>>>>>>>>> > Restlet again!!!!!!!
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> > Joel Bernstein
>>>>>>>>>>> > http://joelsolr.blogspot.com/
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <
>>>>>>>>>>> epugh@opensourceconnections.com> wrote:
>>>>>>>>>>> >>
>>>>>>>>>>> >> Do we have a community blessed alternative to restlet already?
>>>>>>>>>>> >>
>>>>>>>>>>> >> On Sep 20, 2020, at 9:40 AM, Noble Paul <noble.paul@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>> >>
>>>>>>>>>>> >> Haha.
>>>>>>>>>>> >>
>>>>>>>>>>> >> In fact schema APIs don't use restlet. Only the managed
>>>>>>>>>>> resources use it
>>>>>>>>>>> >>
>>>>>>>>>>> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
>>>>>>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> If I were talend, I'd immediately start publishing to maven
>>>>>>>>>>> central. If I were the developer who built the schema APIs, I would never
>>>>>>>>>>> have used restlet to begin with.
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, <
>>>>>>>>>>> uwe@thetaphi.de> wrote:
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> I was thinking the same. Because GitHub does not cache the
>>>>>>>>>>> downloaded artifacts like our jenkins servers.
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> It seems to run it in a new VM or container every time, so
>>>>>>>>>>> it downloads all artifacts. If I were Talend, I'd also block this.
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> Uwe
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
>>>>>>>>>>> dawid.weiss@gmail.com>:
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> I don't think it's http/https - I believe restlet
>>>>>>>>>>> repository simply
>>>>>>>>>>> >>>>> bans github servers because of excessive traffic? These
>>>>>>>>>>> URLs work for
>>>>>>>>>>> >>>>> me locally...
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> Dawid
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke
>>>>>>>>>>> (BLOOMBERG/
>>>>>>>>>>> >>>>> LONDON) <cpoerschke@bloomberg.net> wrote:
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> This sounds vaguely familiar. "http works, https does
>>>>>>>>>>> not work" and https://issues.apache.org/jira/browse/SOLR-13756
>>>>>>>>>>> possibly related?
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> From: dev@lucene.apache.org At: 09/18/20 10:01:29
>>>>>>>>>>> >>>>>> To: dev@lucene.apache.org
>>>>>>>>>>> >>>>>> Subject: Re: restlet dependencies
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> I don't think it is, sadly.
>>>>>>>>>>> >>>>>> https://repo1.maven.org/maven2/org/restlet
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> The link you provided (mvnrepository) aggregates from
>>>>>>>>>>> several maven
>>>>>>>>>>> >>>>>> repositories.
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> D.
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
>>>>>>>>>>> >>>>>> <ichattopadhyaya@gmail.com> wrote:
>>>>>>>>>>> >>>>>>>
>>>>>>>>>>> >>>>>>>
>>>>>>>>>>> >>>>>>> Sorry, afk, but I heard (*hearsay*) that restlet is
>>>>>>>>>>> also on maven central
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> these days. Can we confirm and switch to that? Sorry, if
>>>>>>>>>>> that's not the case.
>>>>>>>>>>> >>>>>>>
>>>>>>>>>>> >>>>>>>
>>>>>>>>>>> >>>>>>> On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <
>>>>>>>>>>> dawid.weiss@gmail.com> wrote:
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>> >>>>>>>> Just FYI: can't get PR builds on github to work
>>>>>>>>>>> recently because of this:
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>> >>>>>>>>> Could not resolve all files for configuration
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> ':solr:core:compileClasspath'.
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>> >>>>>>>> 350 > Could not download
>>>>>>>>>>> org.restlet.ext.servlet-2.4.3.jar
>>>>>>>>>>> >>>>>>>> (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>>>>>>>>>>> >>>>>>>> 351 > Could not get resource
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>> >>>>>> '
>>>>>>>>>>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>>>>>>>>>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>> >>>>>>>> 352 > Could not GET
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>> >>>>>> '
>>>>>>>>>>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>>>>>>>>>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>> >>>>>>>> 353 > Connection reset
>>>>>>>>>>> >>>>>>>> 354 > Could not download org.restlet-2.4.3.jar
>>>>>>>>>>> >>>>>>>> (org.restlet.jee:org.restlet:2.4.3)
>>>>>>>>>>> >>>>>>>> 355 > Could not get resource
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>> >>>>>> '
>>>>>>>>>>> https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
>>>>>>>>>>> >>>>>> ar'.
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>> >>>>>>>> 356 > Could not GET
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>> >>>>>> '
>>>>>>>>>>> https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
>>>>>>>>>>> >>>>>> 2.4.3.jar'.
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>> >>>>>>>> 357 > Connection reset
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>> >>>>>>>> D.
>>>>>>>>>>> >>>>>>>> ________________________________
>>>>>>>>>>> >>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>>> dev-unsubscribe@lucene.apache.org
>>>>>>>>>>> >>>>>>>> For additional commands, e-mail:
>>>>>>>>>>> dev-help@lucene.apache.org
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>> >>>>>> ________________________________
>>>>>>>>>>> >>>>>> To unsubscribe, e-mail:
>>>>>>>>>>> dev-unsubscribe@lucene.apache.org
>>>>>>>>>>> >>>>>> For additional commands, e-mail:
>>>>>>>>>>> dev-help@lucene.apache.org
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>> ________________________________
>>>>>>>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>>>>> >>>>> For additional commands, e-mail:
>>>>>>>>>>> dev-help@lucene.apache.org
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> --
>>>>>>>>>>> >>>> Uwe Schindler
>>>>>>>>>>> >>>> Achterdiek 19, 28357 Bremen
>>>>>>>>>>> >>>> https://www.thetaphi.de
>>>>>>>>>>> >>
>>>>>>>>>>> >>
>>>>>>>>>>> >> _______________________
>>>>>>>>>>> >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
>>>>>>>>>>> 434.466.1467 | http://www.opensourceconnections.com | My
>>>>>>>>>>> Free/Busy
>>>>>>>>>>> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>>>>>>>>>> >> This e-mail and all contents, including attachments, is
>>>>>>>>>>> considered to be Company Confidential unless explicitly stated otherwise,
>>>>>>>>>>> regardless of whether attachments are marked as such.
>>>>>>>>>>> >>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> -----------------------------------------------------
>>>>>>>>>>> Noble Paul
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> _______________________
>>>>>>>> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.
>>>>>>>> 466.1467 | http://www.opensourceconnections.com | My Free/Busy
>>>>>>>> <http://tinyurl.com/eric-cal>
>>>>>>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>>>>>>> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>>>>>>>> This e-mail and all contents, including attachments, is considered
>>>>>>>> to be Company Confidential unless explicitly stated otherwise, regardless
>>>>>>>> of whether attachments are marked as such.
>>>>>>>>
>>>>>>>>
>>>

--
Adrien
Re: restlet dependencies [ In reply to ]
We can upgrade if it doesn't break anything... which I can't guarantee. ;)

Dawid

>
Re: restlet dependencies [ In reply to ]
Can we pull in the jar inside our codebase?

On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <dawid.weiss@gmail.com> wrote:

>
> We can upgrade if it doesn't break anything... which I can't guarantee. ;)
>
> Dawid
>
>>
Re: restlet dependencies [ In reply to ]
I think we should just get rid of that feature in the next release. if
somebody is dependent on that let them stick to 8.6x or 8.7. We should
not bend over backwards to support some esoteric feature nobody uses

Managed Resources has the following problems

* Nobody knows how it works. It's unsupported
* RESTlet dependency
* Cannot be secured using standard permissions
* It's extremely complex for the functionality it offers.

On Wed, Sep 30, 2020 at 6:02 AM Ishan Chattopadhyaya
<ichattopadhyaya@gmail.com> wrote:
>
> Can we pull in the jar inside our codebase?
>
> On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <dawid.weiss@gmail.com> wrote:
>>
>>
>> We can upgrade if it doesn't break anything... which I can't guarantee. ;)
>>
>> Dawid



--
-----------------------------------------------------
Noble Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: restlet dependencies [ In reply to ]
@Tomas Fernandez Lobbe
@Ishan Chattopadhyaya
Let's support the single file upload feature. Let's automatically make
that configset "untrusted" if any file is uploaded over REST. Those
"untrusted" features are not really important for normal users

On Wed, Sep 30, 2020 at 3:19 PM Noble Paul <noble.paul@gmail.com> wrote:
>
> I think we should just get rid of that feature in the next release. if
> somebody is dependent on that let them stick to 8.6x or 8.7. We should
> not bend over backwards to support some esoteric feature nobody uses
>
> Managed Resources has the following problems
>
> * Nobody knows how it works. It's unsupported
> * RESTlet dependency
> * Cannot be secured using standard permissions
> * It's extremely complex for the functionality it offers.
>
> On Wed, Sep 30, 2020 at 6:02 AM Ishan Chattopadhyaya
> <ichattopadhyaya@gmail.com> wrote:
> >
> > Can we pull in the jar inside our codebase?
> >
> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <dawid.weiss@gmail.com> wrote:
> >>
> >>
> >> We can upgrade if it doesn't break anything... which I can't guarantee. ;)
> >>
> >> Dawid
>
>
>
> --
> -----------------------------------------------------
> Noble Paul



--
-----------------------------------------------------
Noble Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: restlet dependencies [ In reply to ]
I don't support removing managed resources in a minor release. Some of my
clients depend on it. Also, single file upload has important security
considerations and we don't have time to have that feature in before 8.7.

On Wed, 30 Sep, 2020, 10:50 am Noble Paul, <noble.paul@gmail.com> wrote:

> @Tomas Fernandez Lobbe
> @Ishan Chattopadhyaya
> Let's support the single file upload feature. Let's automatically make
> that configset "untrusted" if any file is uploaded over REST. Those
> "untrusted" features are not really important for normal users
>
> On Wed, Sep 30, 2020 at 3:19 PM Noble Paul <noble.paul@gmail.com> wrote:
> >
> > I think we should just get rid of that feature in the next release. if
> > somebody is dependent on that let them stick to 8.6x or 8.7. We should
> > not bend over backwards to support some esoteric feature nobody uses
> >
> > Managed Resources has the following problems
> >
> > * Nobody knows how it works. It's unsupported
> > * RESTlet dependency
> > * Cannot be secured using standard permissions
> > * It's extremely complex for the functionality it offers.
> >
> > On Wed, Sep 30, 2020 at 6:02 AM Ishan Chattopadhyaya
> > <ichattopadhyaya@gmail.com> wrote:
> > >
> > > Can we pull in the jar inside our codebase?
> > >
> > > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <dawid.weiss@gmail.com>
> wrote:
> > >>
> > >>
> > >> We can upgrade if it doesn't break anything... which I can't
> guarantee. ;)
> > >>
> > >> Dawid
> >
> >
> >
> > --
> > -----------------------------------------------------
> > Noble Paul
>
>
>
> --
> -----------------------------------------------------
> Noble Paul
>
Re: restlet dependencies [ In reply to ]
We can't have or redistribute binaries in ASL sources - that's my understanding.

Dawid

On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
<ichattopadhyaya@gmail.com> wrote:
>
> Can we pull in the jar inside our codebase?
>
> On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <dawid.weiss@gmail.com> wrote:
>>
>>
>> We can upgrade if it doesn't break anything... which I can't guarantee. ;)
>>
>> Dawid

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: restlet dependencies [ In reply to ]
Can we discuss this with ASF and get an exception for this?

On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, <dawid.weiss@gmail.com> wrote:

> We can't have or redistribute binaries in ASL sources - that's my
> understanding.
>
> Dawid
>
> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
> <ichattopadhyaya@gmail.com> wrote:
> >
> > Can we pull in the jar inside our codebase?
> >
> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <dawid.weiss@gmail.com>
> wrote:
> >>
> >>
> >> We can upgrade if it doesn't break anything... which I can't guarantee.
> ;)
> >>
> >> Dawid
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: restlet dependencies [ In reply to ]
Please don't do this.

In short: remove restlet stuff from master. Pull requests on master are executed with Gradle on GitHub hardware.

Ivy stuff in 8.x is built in more or less persistent servers and there is no issue.

What's the problem?

Uwe

Am September 30, 2020 8:59:06 AM UTC schrieb Ishan Chattopadhyaya <ichattopadhyaya@gmail.com>:
>Can we discuss this with ASF and get an exception for this?
>
>On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, <dawid.weiss@gmail.com>
>wrote:
>
>> We can't have or redistribute binaries in ASL sources - that's my
>> understanding.
>>
>> Dawid
>>
>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
>> <ichattopadhyaya@gmail.com> wrote:
>> >
>> > Can we pull in the jar inside our codebase?
>> >
>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <dawid.weiss@gmail.com>
>> wrote:
>> >>
>> >>
>> >> We can upgrade if it doesn't break anything... which I can't
>guarantee.
>> ;)
>> >>
>> >> Dawid
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de
Re: restlet dependencies [ In reply to ]
The managed resources is the only reasonable way to upload synonyms on the
fly for users today. A single file configset upload would require the user
to reload the collection, so it isn't better than managed resources. I
would not recommend we remove the functionality without first building a
suitable alternative. I agree that the feature isn't built using proper
framework or proper APIs, but it is a feature that works well.

Usually, I support throwing features out even without existence of an
alternative, but I do that for non essential features. In my mind, ability
to manage synonyms elegantly is an essential feature for a search engine.

On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler, <uwe@thetaphi.de> wrote:

> Please don't do this.
>
> In short: remove restlet stuff from master. Pull requests on master are
> executed with Gradle on GitHub hardware.
>
> Ivy stuff in 8.x is built in more or less persistent servers and there is
> no issue.
>
> What's the problem?
>
> Uwe
>
> Am September 30, 2020 8:59:06 AM UTC schrieb Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com>:
>>
>> Can we discuss this with ASF and get an exception for this?
>>
>> On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, <dawid.weiss@gmail.com>
>> wrote:
>>
>>> We can't have or redistribute binaries in ASL sources - that's my
>>> understanding.
>>>
>>> Dawid
>>>
>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
>>> <ichattopadhyaya@gmail.com> wrote:
>>> >
>>> > Can we pull in the jar inside our codebase?
>>> >
>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <dawid.weiss@gmail.com>
>>> wrote:
>>> >>
>>> >>
>>> >> We can upgrade if it doesn't break anything... which I can't
>>> guarantee. ;)
>>> >>
>>> >> Dawid
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de
>
Re: restlet dependencies [ In reply to ]
> * Nobody knows how it works. It's unsupported
It is supported and documented:
https://lucene.apache.org/solr/guide/8_6/managed-resources.html

> * RESTlet dependency
> * Cannot be secured using standard permissions
> * It's extremely complex for the functionality it offers.

I agree. Whatever alternative we build should address these, before we
consider removing managed resources.

On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya <
ichattopadhyaya@gmail.com> wrote:

> The managed resources is the only reasonable way to upload synonyms on the
> fly for users today. A single file configset upload would require the user
> to reload the collection, so it isn't better than managed resources. I
> would not recommend we remove the functionality without first building a
> suitable alternative. I agree that the feature isn't built using proper
> framework or proper APIs, but it is a feature that works well.
>
> Usually, I support throwing features out even without existence of an
> alternative, but I do that for non essential features. In my mind, ability
> to manage synonyms elegantly is an essential feature for a search engine.
>
> On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler, <uwe@thetaphi.de> wrote:
>
>> Please don't do this.
>>
>> In short: remove restlet stuff from master. Pull requests on master are
>> executed with Gradle on GitHub hardware.
>>
>> Ivy stuff in 8.x is built in more or less persistent servers and there is
>> no issue.
>>
>> What's the problem?
>>
>> Uwe
>>
>> Am September 30, 2020 8:59:06 AM UTC schrieb Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com>:
>>>
>>> Can we discuss this with ASF and get an exception for this?
>>>
>>> On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, <dawid.weiss@gmail.com>
>>> wrote:
>>>
>>>> We can't have or redistribute binaries in ASL sources - that's my
>>>> understanding.
>>>>
>>>> Dawid
>>>>
>>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
>>>> <ichattopadhyaya@gmail.com> wrote:
>>>> >
>>>> > Can we pull in the jar inside our codebase?
>>>> >
>>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <dawid.weiss@gmail.com>
>>>> wrote:
>>>> >>
>>>> >>
>>>> >> We can upgrade if it doesn't break anything... which I can't
>>>> guarantee. ;)
>>>> >>
>>>> >> Dawid
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>>
>> --
>> Uwe Schindler
>> Achterdiek 19, 28357 Bremen
>> https://www.thetaphi.de
>>
>
Re: restlet dependencies [ In reply to ]
Definitely don't remove in 8.x!

> A single file configset upload would require the user to reload the
collection, so it isn't better than managed resources.

Do you view that as a substantial point in favor of managed-resources? I
view that as a trivial matter, and one I prefer to automagic and
potentially premature reload if there are additional edits to be done (e.g.
query-elevation or other word lists).

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Wed, Sep 30, 2020 at 5:46 AM Ishan Chattopadhyaya <
ichattopadhyaya@gmail.com> wrote:

> > * Nobody knows how it works. It's unsupported
> It is supported and documented:
> https://lucene.apache.org/solr/guide/8_6/managed-resources.html
>
> > * RESTlet dependency
> > * Cannot be secured using standard permissions
> > * It's extremely complex for the functionality it offers.
>
> I agree. Whatever alternative we build should address these, before we
> consider removing managed resources.
>
> On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
>
>> The managed resources is the only reasonable way to upload synonyms on
>> the fly for users today. A single file configset upload would require the
>> user to reload the collection, so it isn't better than managed resources. I
>> would not recommend we remove the functionality without first building a
>> suitable alternative. I agree that the feature isn't built using proper
>> framework or proper APIs, but it is a feature that works well.
>>
>> Usually, I support throwing features out even without existence of an
>> alternative, but I do that for non essential features. In my mind, ability
>> to manage synonyms elegantly is an essential feature for a search engine.
>>
>> On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler, <uwe@thetaphi.de> wrote:
>>
>>> Please don't do this.
>>>
>>> In short: remove restlet stuff from master. Pull requests on master are
>>> executed with Gradle on GitHub hardware.
>>>
>>> Ivy stuff in 8.x is built in more or less persistent servers and there
>>> is no issue.
>>>
>>> What's the problem?
>>>
>>> Uwe
>>>
>>> Am September 30, 2020 8:59:06 AM UTC schrieb Ishan Chattopadhyaya <
>>> ichattopadhyaya@gmail.com>:
>>>>
>>>> Can we discuss this with ASF and get an exception for this?
>>>>
>>>> On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, <dawid.weiss@gmail.com>
>>>> wrote:
>>>>
>>>>> We can't have or redistribute binaries in ASL sources - that's my
>>>>> understanding.
>>>>>
>>>>> Dawid
>>>>>
>>>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
>>>>> <ichattopadhyaya@gmail.com> wrote:
>>>>> >
>>>>> > Can we pull in the jar inside our codebase?
>>>>> >
>>>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <dawid.weiss@gmail.com>
>>>>> wrote:
>>>>> >>
>>>>> >>
>>>>> >> We can upgrade if it doesn't break anything... which I can't
>>>>> guarantee. ;)
>>>>> >>
>>>>> >> Dawid
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>>
>>> --
>>> Uwe Schindler
>>> Achterdiek 19, 28357 Bremen
>>> https://www.thetaphi.de
>>>
>>
Re: restlet dependencies [ In reply to ]
Core reloads cause caches to be invalidated, hence the query response times
shoot up momentarily. This doesn't happen when using managed synonyms etc,
does it?

On Wed, 30 Sep, 2020, 5:53 pm David Smiley, <dsmiley@apache.org> wrote:

> Definitely don't remove in 8.x!
>
> > A single file configset upload would require the user to reload the
> collection, so it isn't better than managed resources.
>
> Do you view that as a substantial point in favor of managed-resources? I
> view that as a trivial matter, and one I prefer to automagic and
> potentially premature reload if there are additional edits to be done (e.g.
> query-elevation or other word lists).
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Sep 30, 2020 at 5:46 AM Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
>
>> > * Nobody knows how it works. It's unsupported
>> It is supported and documented:
>> https://lucene.apache.org/solr/guide/8_6/managed-resources.html
>>
>> > * RESTlet dependency
>> > * Cannot be secured using standard permissions
>> > * It's extremely complex for the functionality it offers.
>>
>> I agree. Whatever alternative we build should address these, before we
>> consider removing managed resources.
>>
>> On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> wrote:
>>
>>> The managed resources is the only reasonable way to upload synonyms on
>>> the fly for users today. A single file configset upload would require the
>>> user to reload the collection, so it isn't better than managed resources. I
>>> would not recommend we remove the functionality without first building a
>>> suitable alternative. I agree that the feature isn't built using proper
>>> framework or proper APIs, but it is a feature that works well.
>>>
>>> Usually, I support throwing features out even without existence of an
>>> alternative, but I do that for non essential features. In my mind, ability
>>> to manage synonyms elegantly is an essential feature for a search engine.
>>>
>>> On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler, <uwe@thetaphi.de> wrote:
>>>
>>>> Please don't do this.
>>>>
>>>> In short: remove restlet stuff from master. Pull requests on master are
>>>> executed with Gradle on GitHub hardware.
>>>>
>>>> Ivy stuff in 8.x is built in more or less persistent servers and there
>>>> is no issue.
>>>>
>>>> What's the problem?
>>>>
>>>> Uwe
>>>>
>>>> Am September 30, 2020 8:59:06 AM UTC schrieb Ishan Chattopadhyaya <
>>>> ichattopadhyaya@gmail.com>:
>>>>>
>>>>> Can we discuss this with ASF and get an exception for this?
>>>>>
>>>>> On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, <dawid.weiss@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> We can't have or redistribute binaries in ASL sources - that's my
>>>>>> understanding.
>>>>>>
>>>>>> Dawid
>>>>>>
>>>>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
>>>>>> <ichattopadhyaya@gmail.com> wrote:
>>>>>> >
>>>>>> > Can we pull in the jar inside our codebase?
>>>>>> >
>>>>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <dawid.weiss@gmail.com>
>>>>>> wrote:
>>>>>> >>
>>>>>> >>
>>>>>> >> We can upgrade if it doesn't break anything... which I can't
>>>>>> guarantee. ;)
>>>>>> >>
>>>>>> >> Dawid
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>
>>>>>>
>>>> --
>>>> Uwe Schindler
>>>> Achterdiek 19, 28357 Bremen
>>>> https://www.thetaphi.de
>>>>
>>>
Re: restlet dependencies [ In reply to ]
>It is supported and documented: https://lucene.apache.org/solr/guide/8_6/managed-resources.html

I was referring to how the code works. Not how the feature works

On Wed, Sep 30, 2020 at 7:46 PM Ishan Chattopadhyaya
<ichattopadhyaya@gmail.com> wrote:
>
> > * Nobody knows how it works. It's unsupported
> It is supported and documented: https://lucene.apache.org/solr/guide/8_6/managed-resources.html
>
> > * RESTlet dependency
> > * Cannot be secured using standard permissions
> > * It's extremely complex for the functionality it offers.
>
> I agree. Whatever alternative we build should address these, before we consider removing managed resources.
>
> On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya <ichattopadhyaya@gmail.com> wrote:
>>
>> The managed resources is the only reasonable way to upload synonyms on the fly for users today. A single file configset upload would require the user to reload the collection, so it isn't better than managed resources. I would not recommend we remove the functionality without first building a suitable alternative. I agree that the feature isn't built using proper framework or proper APIs, but it is a feature that works well.
>>
>> Usually, I support throwing features out even without existence of an alternative, but I do that for non essential features. In my mind, ability to manage synonyms elegantly is an essential feature for a search engine.
>>
>> On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler, <uwe@thetaphi.de> wrote:
>>>
>>> Please don't do this.
>>>
>>> In short: remove restlet stuff from master. Pull requests on master are executed with Gradle on GitHub hardware.
>>>
>>> Ivy stuff in 8.x is built in more or less persistent servers and there is no issue.
>>>
>>> What's the problem?
>>>
>>> Uwe
>>>
>>> Am September 30, 2020 8:59:06 AM UTC schrieb Ishan Chattopadhyaya <ichattopadhyaya@gmail.com>:
>>>>
>>>> Can we discuss this with ASF and get an exception for this?
>>>>
>>>> On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, <dawid.weiss@gmail.com> wrote:
>>>>>
>>>>> We can't have or redistribute binaries in ASL sources - that's my understanding.
>>>>>
>>>>> Dawid
>>>>>
>>>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
>>>>> <ichattopadhyaya@gmail.com> wrote:
>>>>> >
>>>>> > Can we pull in the jar inside our codebase?
>>>>> >
>>>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <dawid.weiss@gmail.com> wrote:
>>>>> >>
>>>>> >>
>>>>> >> We can upgrade if it doesn't break anything... which I can't guarantee. ;)
>>>>> >>
>>>>> >> Dawid
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>
>>> --
>>> Uwe Schindler
>>> Achterdiek 19, 28357 Bremen
>>> https://www.thetaphi.de



--
-----------------------------------------------------
Noble Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: restlet dependencies [ In reply to ]
Well, I believe we should have a mechanism to upload a single file to
a configset.

> A single file configset upload would require the user to reload the collection, so it isn't better than managed resources.

This is not true

Only config/schema file changes result in core reload.

On Wed, Sep 30, 2020 at 10:23 PM David Smiley <dsmiley@apache.org> wrote:
>
> Definitely don't remove in 8.x!
>
> > A single file configset upload would require the user to reload the collection, so it isn't better than managed resources.
>
> Do you view that as a substantial point in favor of managed-resources? I view that as a trivial matter, and one I prefer to automagic and potentially premature reload if there are additional edits to be done (e.g. query-elevation or other word lists).
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Sep 30, 2020 at 5:46 AM Ishan Chattopadhyaya <ichattopadhyaya@gmail.com> wrote:
>>
>> > * Nobody knows how it works. It's unsupported
>> It is supported and documented: https://lucene.apache.org/solr/guide/8_6/managed-resources.html
>>
>> > * RESTlet dependency
>> > * Cannot be secured using standard permissions
>> > * It's extremely complex for the functionality it offers.
>>
>> I agree. Whatever alternative we build should address these, before we consider removing managed resources.
>>
>> On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya <ichattopadhyaya@gmail.com> wrote:
>>>
>>> The managed resources is the only reasonable way to upload synonyms on the fly for users today. A single file configset upload would require the user to reload the collection, so it isn't better than managed resources. I would not recommend we remove the functionality without first building a suitable alternative. I agree that the feature isn't built using proper framework or proper APIs, but it is a feature that works well.
>>>
>>> Usually, I support throwing features out even without existence of an alternative, but I do that for non essential features. In my mind, ability to manage synonyms elegantly is an essential feature for a search engine.
>>>
>>> On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler, <uwe@thetaphi.de> wrote:
>>>>
>>>> Please don't do this.
>>>>
>>>> In short: remove restlet stuff from master. Pull requests on master are executed with Gradle on GitHub hardware.
>>>>
>>>> Ivy stuff in 8.x is built in more or less persistent servers and there is no issue.
>>>>
>>>> What's the problem?
>>>>
>>>> Uwe
>>>>
>>>> Am September 30, 2020 8:59:06 AM UTC schrieb Ishan Chattopadhyaya <ichattopadhyaya@gmail.com>:
>>>>>
>>>>> Can we discuss this with ASF and get an exception for this?
>>>>>
>>>>> On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, <dawid.weiss@gmail.com> wrote:
>>>>>>
>>>>>> We can't have or redistribute binaries in ASL sources - that's my understanding.
>>>>>>
>>>>>> Dawid
>>>>>>
>>>>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
>>>>>> <ichattopadhyaya@gmail.com> wrote:
>>>>>> >
>>>>>> > Can we pull in the jar inside our codebase?
>>>>>> >
>>>>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <dawid.weiss@gmail.com> wrote:
>>>>>> >>
>>>>>> >>
>>>>>> >> We can upgrade if it doesn't break anything... which I can't guarantee. ;)
>>>>>> >>
>>>>>> >> Dawid
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>
>>>>
>>>> --
>>>> Uwe Schindler
>>>> Achterdiek 19, 28357 Bremen
>>>> https://www.thetaphi.de



--
-----------------------------------------------------
Noble Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: restlet dependencies [ In reply to ]
These resources are fundamentally a part of the configSet and can (in
general) affect query results and thus flushing caches (via a reload) is
appropriate.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Wed, Sep 30, 2020 at 9:06 AM Noble Paul <noble.paul@gmail.com> wrote:

> Well, I believe we should have a mechanism to upload a single file to
> a configset.
>
> > A single file configset upload would require the user to reload the
> collection, so it isn't better than managed resources.
>
> This is not true
>
> Only config/schema file changes result in core reload.
>
> On Wed, Sep 30, 2020 at 10:23 PM David Smiley <dsmiley@apache.org> wrote:
> >
> > Definitely don't remove in 8.x!
> >
> > > A single file configset upload would require the user to reload the
> collection, so it isn't better than managed resources.
> >
> > Do you view that as a substantial point in favor of managed-resources?
> I view that as a trivial matter, and one I prefer to automagic and
> potentially premature reload if there are additional edits to be done (e.g.
> query-elevation or other word lists).
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley
> >
> >
> > On Wed, Sep 30, 2020 at 5:46 AM Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
> >>
> >> > * Nobody knows how it works. It's unsupported
> >> It is supported and documented:
> https://lucene.apache.org/solr/guide/8_6/managed-resources.html
> >>
> >> > * RESTlet dependency
> >> > * Cannot be secured using standard permissions
> >> > * It's extremely complex for the functionality it offers.
> >>
> >> I agree. Whatever alternative we build should address these, before we
> consider removing managed resources.
> >>
> >> On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
> >>>
> >>> The managed resources is the only reasonable way to upload synonyms on
> the fly for users today. A single file configset upload would require the
> user to reload the collection, so it isn't better than managed resources. I
> would not recommend we remove the functionality without first building a
> suitable alternative. I agree that the feature isn't built using proper
> framework or proper APIs, but it is a feature that works well.
> >>>
> >>> Usually, I support throwing features out even without existence of an
> alternative, but I do that for non essential features. In my mind, ability
> to manage synonyms elegantly is an essential feature for a search engine.
> >>>
> >>> On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler, <uwe@thetaphi.de> wrote:
> >>>>
> >>>> Please don't do this.
> >>>>
> >>>> In short: remove restlet stuff from master. Pull requests on master
> are executed with Gradle on GitHub hardware.
> >>>>
> >>>> Ivy stuff in 8.x is built in more or less persistent servers and
> there is no issue.
> >>>>
> >>>> What's the problem?
> >>>>
> >>>> Uwe
> >>>>
> >>>> Am September 30, 2020 8:59:06 AM UTC schrieb Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com>:
> >>>>>
> >>>>> Can we discuss this with ASF and get an exception for this?
> >>>>>
> >>>>> On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, <dawid.weiss@gmail.com>
> wrote:
> >>>>>>
> >>>>>> We can't have or redistribute binaries in ASL sources - that's my
> understanding.
> >>>>>>
> >>>>>> Dawid
> >>>>>>
> >>>>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
> >>>>>> <ichattopadhyaya@gmail.com> wrote:
> >>>>>> >
> >>>>>> > Can we pull in the jar inside our codebase?
> >>>>>> >
> >>>>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <dawid.weiss@gmail.com>
> wrote:
> >>>>>> >>
> >>>>>> >>
> >>>>>> >> We can upgrade if it doesn't break anything... which I can't
> guarantee. ;)
> >>>>>> >>
> >>>>>> >> Dawid
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>>>
> >>>>
> >>>> --
> >>>> Uwe Schindler
> >>>> Achterdiek 19, 28357 Bremen
> >>>> https://www.thetaphi.de
>
>
>
> --
> -----------------------------------------------------
> Noble Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: restlet dependencies [ In reply to ]
I started looking into removing Managed Resources in master and wanted to
mention that the LTR contrib also relies on this framework
(ManagedModelStore and ManagedFeatureStore, see:
https://lucene.apache.org/solr/guide/8_6/learning-to-rank.html#uploading-a-model).
I only mention this b/c it's been said several times in this thread that
nobody uses this feature and it's only for editing config/schema like
synonyms. Afaik, LTR is a broadly used feature of Solr so now I'm not so
bullish on removing the ability to manage dynamic resources using a REST
like API. I agree that changing resources like the synonym set could be
replaced with configSet updates but I don't see how to replace the RESTful
model / feature store API w/o something like Managed Resources?

From where I sit, I think we should just remove the use of restlet in the
implementation but keep the API for Solr 9 (master).

@Ishan ~ you mentioned there is a way to get REST API like behavior w/o
using JAX-RS / Jersey ... something about annotations? Can you point me to
some example code of how that is done please?

Cheers,
Tim

On Wed, Sep 30, 2020 at 8:29 AM David Smiley <dsmiley@apache.org> wrote:

> These resources are fundamentally a part of the configSet and can (in
> general) affect query results and thus flushing caches (via a reload) is
> appropriate.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Sep 30, 2020 at 9:06 AM Noble Paul <noble.paul@gmail.com> wrote:
>
>> Well, I believe we should have a mechanism to upload a single file to
>> a configset.
>>
>> > A single file configset upload would require the user to reload the
>> collection, so it isn't better than managed resources.
>>
>> This is not true
>>
>> Only config/schema file changes result in core reload.
>>
>> On Wed, Sep 30, 2020 at 10:23 PM David Smiley <dsmiley@apache.org> wrote:
>> >
>> > Definitely don't remove in 8.x!
>> >
>> > > A single file configset upload would require the user to reload the
>> collection, so it isn't better than managed resources.
>> >
>> > Do you view that as a substantial point in favor of managed-resources?
>> I view that as a trivial matter, and one I prefer to automagic and
>> potentially premature reload if there are additional edits to be done (e.g.
>> query-elevation or other word lists).
>> >
>> > ~ David Smiley
>> > Apache Lucene/Solr Search Developer
>> > http://www.linkedin.com/in/davidwsmiley
>> >
>> >
>> > On Wed, Sep 30, 2020 at 5:46 AM Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> wrote:
>> >>
>> >> > * Nobody knows how it works. It's unsupported
>> >> It is supported and documented:
>> https://lucene.apache.org/solr/guide/8_6/managed-resources.html
>> >>
>> >> > * RESTlet dependency
>> >> > * Cannot be secured using standard permissions
>> >> > * It's extremely complex for the functionality it offers.
>> >>
>> >> I agree. Whatever alternative we build should address these, before we
>> consider removing managed resources.
>> >>
>> >> On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> wrote:
>> >>>
>> >>> The managed resources is the only reasonable way to upload synonyms
>> on the fly for users today. A single file configset upload would require
>> the user to reload the collection, so it isn't better than managed
>> resources. I would not recommend we remove the functionality without first
>> building a suitable alternative. I agree that the feature isn't built using
>> proper framework or proper APIs, but it is a feature that works well.
>> >>>
>> >>> Usually, I support throwing features out even without existence of an
>> alternative, but I do that for non essential features. In my mind, ability
>> to manage synonyms elegantly is an essential feature for a search engine.
>> >>>
>> >>> On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler, <uwe@thetaphi.de> wrote:
>> >>>>
>> >>>> Please don't do this.
>> >>>>
>> >>>> In short: remove restlet stuff from master. Pull requests on master
>> are executed with Gradle on GitHub hardware.
>> >>>>
>> >>>> Ivy stuff in 8.x is built in more or less persistent servers and
>> there is no issue.
>> >>>>
>> >>>> What's the problem?
>> >>>>
>> >>>> Uwe
>> >>>>
>> >>>> Am September 30, 2020 8:59:06 AM UTC schrieb Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com>:
>> >>>>>
>> >>>>> Can we discuss this with ASF and get an exception for this?
>> >>>>>
>> >>>>> On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, <dawid.weiss@gmail.com>
>> wrote:
>> >>>>>>
>> >>>>>> We can't have or redistribute binaries in ASL sources - that's my
>> understanding.
>> >>>>>>
>> >>>>>> Dawid
>> >>>>>>
>> >>>>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
>> >>>>>> <ichattopadhyaya@gmail.com> wrote:
>> >>>>>> >
>> >>>>>> > Can we pull in the jar inside our codebase?
>> >>>>>> >
>> >>>>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <
>> dawid.weiss@gmail.com> wrote:
>> >>>>>> >>
>> >>>>>> >>
>> >>>>>> >> We can upgrade if it doesn't break anything... which I can't
>> guarantee. ;)
>> >>>>>> >>
>> >>>>>> >> Dawid
>> >>>>>>
>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>>>>>
>> >>>>
>> >>>> --
>> >>>> Uwe Schindler
>> >>>> Achterdiek 19, 28357 Bremen
>> >>>> https://www.thetaphi.de
>>
>>
>>
>> --
>> -----------------------------------------------------
>> Noble Paul
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
Re: restlet dependencies [ In reply to ]
The use case of “I want to update something via a API” is I think pretty common, and it would be nice to make it a single pattern (the annotations?) with lots of examples/developer docs for the next person.



> On Sep 30, 2020, at 11:04 AM, Timothy Potter <thelabdude@gmail.com> wrote:
>
> I started looking into removing Managed Resources in master and wanted to mention that the LTR contrib also relies on this framework (ManagedModelStore and ManagedFeatureStore, see: https://lucene.apache.org/solr/guide/8_6/learning-to-rank.html#uploading-a-model <https://lucene.apache.org/solr/guide/8_6/learning-to-rank.html#uploading-a-model>). I only mention this b/c it's been said several times in this thread that nobody uses this feature and it's only for editing config/schema like synonyms. Afaik, LTR is a broadly used feature of Solr so now I'm not so bullish on removing the ability to manage dynamic resources using a REST like API. I agree that changing resources like the synonym set could be replaced with configSet updates but I don't see how to replace the RESTful model / feature store API w/o something like Managed Resources?
>
> From where I sit, I think we should just remove the use of restlet in the implementation but keep the API for Solr 9 (master).
>
> @Ishan ~ you mentioned there is a way to get REST API like behavior w/o using JAX-RS / Jersey ... something about annotations? Can you point me to some example code of how that is done please?
>
> Cheers,
> Tim
>
> On Wed, Sep 30, 2020 at 8:29 AM David Smiley <dsmiley@apache.org <mailto:dsmiley@apache.org>> wrote:
> These resources are fundamentally a part of the configSet and can (in general) affect query results and thus flushing caches (via a reload) is appropriate.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley <http://www.linkedin.com/in/davidwsmiley>
>
> On Wed, Sep 30, 2020 at 9:06 AM Noble Paul <noble.paul@gmail.com <mailto:noble.paul@gmail.com>> wrote:
> Well, I believe we should have a mechanism to upload a single file to
> a configset.
>
> > A single file configset upload would require the user to reload the collection, so it isn't better than managed resources.
>
> This is not true
>
> Only config/schema file changes result in core reload.
>
> On Wed, Sep 30, 2020 at 10:23 PM David Smiley <dsmiley@apache.org <mailto:dsmiley@apache.org>> wrote:
> >
> > Definitely don't remove in 8.x!
> >
> > > A single file configset upload would require the user to reload the collection, so it isn't better than managed resources.
> >
> > Do you view that as a substantial point in favor of managed-resources? I view that as a trivial matter, and one I prefer to automagic and potentially premature reload if there are additional edits to be done (e.g. query-elevation or other word lists).
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley <http://www.linkedin.com/in/davidwsmiley>
> >
> >
> > On Wed, Sep 30, 2020 at 5:46 AM Ishan Chattopadhyaya <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com>> wrote:
> >>
> >> > * Nobody knows how it works. It's unsupported
> >> It is supported and documented: https://lucene.apache.org/solr/guide/8_6/managed-resources.html <https://lucene.apache.org/solr/guide/8_6/managed-resources.html>
> >>
> >> > * RESTlet dependency
> >> > * Cannot be secured using standard permissions
> >> > * It's extremely complex for the functionality it offers.
> >>
> >> I agree. Whatever alternative we build should address these, before we consider removing managed resources.
> >>
> >> On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com>> wrote:
> >>>
> >>> The managed resources is the only reasonable way to upload synonyms on the fly for users today. A single file configset upload would require the user to reload the collection, so it isn't better than managed resources. I would not recommend we remove the functionality without first building a suitable alternative. I agree that the feature isn't built using proper framework or proper APIs, but it is a feature that works well.
> >>>
> >>> Usually, I support throwing features out even without existence of an alternative, but I do that for non essential features. In my mind, ability to manage synonyms elegantly is an essential feature for a search engine.
> >>>
> >>> On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler, <uwe@thetaphi.de <mailto:uwe@thetaphi.de>> wrote:
> >>>>
> >>>> Please don't do this.
> >>>>
> >>>> In short: remove restlet stuff from master. Pull requests on master are executed with Gradle on GitHub hardware.
> >>>>
> >>>> Ivy stuff in 8.x is built in more or less persistent servers and there is no issue.
> >>>>
> >>>> What's the problem?
> >>>>
> >>>> Uwe
> >>>>
> >>>> Am September 30, 2020 8:59:06 AM UTC schrieb Ishan Chattopadhyaya <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com>>:
> >>>>>
> >>>>> Can we discuss this with ASF and get an exception for this?
> >>>>>
> >>>>> On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, <dawid.weiss@gmail.com <mailto:dawid.weiss@gmail.com>> wrote:
> >>>>>>
> >>>>>> We can't have or redistribute binaries in ASL sources - that's my understanding.
> >>>>>>
> >>>>>> Dawid
> >>>>>>
> >>>>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
> >>>>>> <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com>> wrote:
> >>>>>> >
> >>>>>> > Can we pull in the jar inside our codebase?
> >>>>>> >
> >>>>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <dawid.weiss@gmail.com <mailto:dawid.weiss@gmail.com>> wrote:
> >>>>>> >>
> >>>>>> >>
> >>>>>> >> We can upgrade if it doesn't break anything... which I can't guarantee. ;)
> >>>>>> >>
> >>>>>> >> Dawid
> >>>>>>
> >>>>>> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
> >>>>>>
> >>>>
> >>>> --
> >>>> Uwe Schindler
> >>>> Achterdiek 19, 28357 Bremen
> >>>> https://www.thetaphi.de <https://www.thetaphi.de/>
>
>
>
> --
> -----------------------------------------------------
> Noble Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
>

_______________________
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal>
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
Re: restlet dependencies [ In reply to ]
I'm sorry, I don't understand what you mean by "make it a single pattern
(the annotations?)" Eric?

To me, the pattern is well established in the Java world: JAX-RS (with
Jersey as the underlying impl. which has nice integration with Jetty). But
when I suggested porting the code that uses restlet to JAX-RS / Jersey,
Ishan said that wasn't necessary and is already supported with some
Annotations ... I have no idea what that means and need more info about
what is already in place. Short of that, replacing restlet with JAX-RS /
Jersey looks like a trivial amount of work to me (and I'm happy to take it
on).

Tim

On Wed, Sep 30, 2020 at 9:36 AM Eric Pugh <epugh@opensourceconnections.com>
wrote:

> The use case of “I want to update something via a API” is I think pretty
> common, and it would be nice to make it a single pattern (the annotations?)
> with lots of examples/developer docs for the next person.
>
>
>
> On Sep 30, 2020, at 11:04 AM, Timothy Potter <thelabdude@gmail.com> wrote:
>
> I started looking into removing Managed Resources in master and wanted to
> mention that the LTR contrib also relies on this framework
> (ManagedModelStore and ManagedFeatureStore, see:
> https://lucene.apache.org/solr/guide/8_6/learning-to-rank.html#uploading-a-model).
> I only mention this b/c it's been said several times in this thread that
> nobody uses this feature and it's only for editing config/schema like
> synonyms. Afaik, LTR is a broadly used feature of Solr so now I'm not so
> bullish on removing the ability to manage dynamic resources using a REST
> like API. I agree that changing resources like the synonym set could be
> replaced with configSet updates but I don't see how to replace the RESTful
> model / feature store API w/o something like Managed Resources?
>
> From where I sit, I think we should just remove the use of restlet in the
> implementation but keep the API for Solr 9 (master).
>
> @Ishan ~ you mentioned there is a way to get REST API like behavior w/o
> using JAX-RS / Jersey ... something about annotations? Can you point me to
> some example code of how that is done please?
>
> Cheers,
> Tim
>
> On Wed, Sep 30, 2020 at 8:29 AM David Smiley <dsmiley@apache.org> wrote:
>
>> These resources are fundamentally a part of the configSet and can (in
>> general) affect query results and thus flushing caches (via a reload) is
>> appropriate.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Wed, Sep 30, 2020 at 9:06 AM Noble Paul <noble.paul@gmail.com> wrote:
>>
>>> Well, I believe we should have a mechanism to upload a single file to
>>> a configset.
>>>
>>> > A single file configset upload would require the user to reload the
>>> collection, so it isn't better than managed resources.
>>>
>>> This is not true
>>>
>>> Only config/schema file changes result in core reload.
>>>
>>> On Wed, Sep 30, 2020 at 10:23 PM David Smiley <dsmiley@apache.org>
>>> wrote:
>>> >
>>> > Definitely don't remove in 8.x!
>>> >
>>> > > A single file configset upload would require the user to reload the
>>> collection, so it isn't better than managed resources.
>>> >
>>> > Do you view that as a substantial point in favor of
>>> managed-resources? I view that as a trivial matter, and one I prefer to
>>> automagic and potentially premature reload if there are additional edits to
>>> be done (e.g. query-elevation or other word lists).
>>> >
>>> > ~ David Smiley
>>> > Apache Lucene/Solr Search Developer
>>> > http://www.linkedin.com/in/davidwsmiley
>>> >
>>> >
>>> > On Wed, Sep 30, 2020 at 5:46 AM Ishan Chattopadhyaya <
>>> ichattopadhyaya@gmail.com> wrote:
>>> >>
>>> >> > * Nobody knows how it works. It's unsupported
>>> >> It is supported and documented:
>>> https://lucene.apache.org/solr/guide/8_6/managed-resources.html
>>> >>
>>> >> > * RESTlet dependency
>>> >> > * Cannot be secured using standard permissions
>>> >> > * It's extremely complex for the functionality it offers.
>>> >>
>>> >> I agree. Whatever alternative we build should address these, before
>>> we consider removing managed resources.
>>> >>
>>> >> On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya <
>>> ichattopadhyaya@gmail.com> wrote:
>>> >>>
>>> >>> The managed resources is the only reasonable way to upload synonyms
>>> on the fly for users today. A single file configset upload would require
>>> the user to reload the collection, so it isn't better than managed
>>> resources. I would not recommend we remove the functionality without first
>>> building a suitable alternative. I agree that the feature isn't built using
>>> proper framework or proper APIs, but it is a feature that works well.
>>> >>>
>>> >>> Usually, I support throwing features out even without existence of
>>> an alternative, but I do that for non essential features. In my mind,
>>> ability to manage synonyms elegantly is an essential feature for a search
>>> engine.
>>> >>>
>>> >>> On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler, <uwe@thetaphi.de>
>>> wrote:
>>> >>>>
>>> >>>> Please don't do this.
>>> >>>>
>>> >>>> In short: remove restlet stuff from master. Pull requests on master
>>> are executed with Gradle on GitHub hardware.
>>> >>>>
>>> >>>> Ivy stuff in 8.x is built in more or less persistent servers and
>>> there is no issue.
>>> >>>>
>>> >>>> What's the problem?
>>> >>>>
>>> >>>> Uwe
>>> >>>>
>>> >>>> Am September 30, 2020 8:59:06 AM UTC schrieb Ishan Chattopadhyaya <
>>> ichattopadhyaya@gmail.com>:
>>> >>>>>
>>> >>>>> Can we discuss this with ASF and get an exception for this?
>>> >>>>>
>>> >>>>> On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, <dawid.weiss@gmail.com>
>>> wrote:
>>> >>>>>>
>>> >>>>>> We can't have or redistribute binaries in ASL sources - that's my
>>> understanding.
>>> >>>>>>
>>> >>>>>> Dawid
>>> >>>>>>
>>> >>>>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
>>> >>>>>> <ichattopadhyaya@gmail.com> wrote:
>>> >>>>>> >
>>> >>>>>> > Can we pull in the jar inside our codebase?
>>> >>>>>> >
>>> >>>>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <
>>> dawid.weiss@gmail.com> wrote:
>>> >>>>>> >>
>>> >>>>>> >>
>>> >>>>>> >> We can upgrade if it doesn't break anything... which I can't
>>> guarantee. ;)
>>> >>>>>> >>
>>> >>>>>> >> Dawid
>>> >>>>>>
>>> >>>>>>
>>> ---------------------------------------------------------------------
>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>>>>>
>>> >>>>
>>> >>>> --
>>> >>>> Uwe Schindler
>>> >>>> Achterdiek 19, 28357 Bremen
>>> >>>> https://www.thetaphi.de
>>>
>>>
>>>
>>> --
>>> -----------------------------------------------------
>>> Noble Paul
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
> _______________________
> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
> | http://www.opensourceconnections.com | My Free/Busy
> <http://tinyurl.com/eric-cal>
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
> This e-mail and all contents, including attachments, is considered to be
> Company Confidential unless explicitly stated otherwise, regardless
> of whether attachments are marked as such.
>
>
Re: restlet dependencies [ In reply to ]
I think that me in “violent agreement” with you. Let’s understand the Annotations approach that we have, or pick something that is commonly used like JAX-RS / Jersey.



> On Sep 30, 2020, at 11:41 AM, Timothy Potter <thelabdude@gmail.com> wrote:
>
> I'm sorry, I don't understand what you mean by "make it a single pattern (the annotations?)" Eric?
>
> To me, the pattern is well established in the Java world: JAX-RS (with Jersey as the underlying impl. which has nice integration with Jetty). But when I suggested porting the code that uses restlet to JAX-RS / Jersey, Ishan said that wasn't necessary and is already supported with some Annotations ... I have no idea what that means and need more info about what is already in place. Short of that, replacing restlet with JAX-RS / Jersey looks like a trivial amount of work to me (and I'm happy to take it on).
>
> Tim
>
> On Wed, Sep 30, 2020 at 9:36 AM Eric Pugh <epugh@opensourceconnections.com <mailto:epugh@opensourceconnections.com>> wrote:
> The use case of “I want to update something via a API” is I think pretty common, and it would be nice to make it a single pattern (the annotations?) with lots of examples/developer docs for the next person.
>
>
>
>> On Sep 30, 2020, at 11:04 AM, Timothy Potter <thelabdude@gmail.com <mailto:thelabdude@gmail.com>> wrote:
>>
>> I started looking into removing Managed Resources in master and wanted to mention that the LTR contrib also relies on this framework (ManagedModelStore and ManagedFeatureStore, see: https://lucene.apache.org/solr/guide/8_6/learning-to-rank.html#uploading-a-model <https://lucene.apache.org/solr/guide/8_6/learning-to-rank.html#uploading-a-model>). I only mention this b/c it's been said several times in this thread that nobody uses this feature and it's only for editing config/schema like synonyms. Afaik, LTR is a broadly used feature of Solr so now I'm not so bullish on removing the ability to manage dynamic resources using a REST like API. I agree that changing resources like the synonym set could be replaced with configSet updates but I don't see how to replace the RESTful model / feature store API w/o something like Managed Resources?
>>
>> From where I sit, I think we should just remove the use of restlet in the implementation but keep the API for Solr 9 (master).
>>
>> @Ishan ~ you mentioned there is a way to get REST API like behavior w/o using JAX-RS / Jersey ... something about annotations? Can you point me to some example code of how that is done please?
>>
>> Cheers,
>> Tim
>>
>> On Wed, Sep 30, 2020 at 8:29 AM David Smiley <dsmiley@apache.org <mailto:dsmiley@apache.org>> wrote:
>> These resources are fundamentally a part of the configSet and can (in general) affect query results and thus flushing caches (via a reload) is appropriate.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley <http://www.linkedin.com/in/davidwsmiley>
>>
>> On Wed, Sep 30, 2020 at 9:06 AM Noble Paul <noble.paul@gmail.com <mailto:noble.paul@gmail.com>> wrote:
>> Well, I believe we should have a mechanism to upload a single file to
>> a configset.
>>
>> > A single file configset upload would require the user to reload the collection, so it isn't better than managed resources.
>>
>> This is not true
>>
>> Only config/schema file changes result in core reload.
>>
>> On Wed, Sep 30, 2020 at 10:23 PM David Smiley <dsmiley@apache.org <mailto:dsmiley@apache.org>> wrote:
>> >
>> > Definitely don't remove in 8.x!
>> >
>> > > A single file configset upload would require the user to reload the collection, so it isn't better than managed resources.
>> >
>> > Do you view that as a substantial point in favor of managed-resources? I view that as a trivial matter, and one I prefer to automagic and potentially premature reload if there are additional edits to be done (e.g. query-elevation or other word lists).
>> >
>> > ~ David Smiley
>> > Apache Lucene/Solr Search Developer
>> > http://www.linkedin.com/in/davidwsmiley <http://www.linkedin.com/in/davidwsmiley>
>> >
>> >
>> > On Wed, Sep 30, 2020 at 5:46 AM Ishan Chattopadhyaya <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com>> wrote:
>> >>
>> >> > * Nobody knows how it works. It's unsupported
>> >> It is supported and documented: https://lucene.apache.org/solr/guide/8_6/managed-resources.html <https://lucene.apache.org/solr/guide/8_6/managed-resources.html>
>> >>
>> >> > * RESTlet dependency
>> >> > * Cannot be secured using standard permissions
>> >> > * It's extremely complex for the functionality it offers.
>> >>
>> >> I agree. Whatever alternative we build should address these, before we consider removing managed resources.
>> >>
>> >> On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com>> wrote:
>> >>>
>> >>> The managed resources is the only reasonable way to upload synonyms on the fly for users today. A single file configset upload would require the user to reload the collection, so it isn't better than managed resources. I would not recommend we remove the functionality without first building a suitable alternative. I agree that the feature isn't built using proper framework or proper APIs, but it is a feature that works well.
>> >>>
>> >>> Usually, I support throwing features out even without existence of an alternative, but I do that for non essential features. In my mind, ability to manage synonyms elegantly is an essential feature for a search engine.
>> >>>
>> >>> On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler, <uwe@thetaphi.de <mailto:uwe@thetaphi.de>> wrote:
>> >>>>
>> >>>> Please don't do this.
>> >>>>
>> >>>> In short: remove restlet stuff from master. Pull requests on master are executed with Gradle on GitHub hardware.
>> >>>>
>> >>>> Ivy stuff in 8.x is built in more or less persistent servers and there is no issue.
>> >>>>
>> >>>> What's the problem?
>> >>>>
>> >>>> Uwe
>> >>>>
>> >>>> Am September 30, 2020 8:59:06 AM UTC schrieb Ishan Chattopadhyaya <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com>>:
>> >>>>>
>> >>>>> Can we discuss this with ASF and get an exception for this?
>> >>>>>
>> >>>>> On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, <dawid.weiss@gmail.com <mailto:dawid.weiss@gmail.com>> wrote:
>> >>>>>>
>> >>>>>> We can't have or redistribute binaries in ASL sources - that's my understanding.
>> >>>>>>
>> >>>>>> Dawid
>> >>>>>>
>> >>>>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
>> >>>>>> <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com>> wrote:
>> >>>>>> >
>> >>>>>> > Can we pull in the jar inside our codebase?
>> >>>>>> >
>> >>>>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <dawid.weiss@gmail.com <mailto:dawid.weiss@gmail.com>> wrote:
>> >>>>>> >>
>> >>>>>> >>
>> >>>>>> >> We can upgrade if it doesn't break anything... which I can't guarantee. ;)
>> >>>>>> >>
>> >>>>>> >> Dawid
>> >>>>>>
>> >>>>>> ---------------------------------------------------------------------
>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
>> >>>>>>
>> >>>>
>> >>>> --
>> >>>> Uwe Schindler
>> >>>> Achterdiek 19, 28357 Bremen
>> >>>> https://www.thetaphi.de <https://www.thetaphi.de/>
>>
>>
>>
>> --
>> -----------------------------------------------------
>> Noble Paul
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
>> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
>>
>
> _______________________
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal>
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
>

_______________________
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal>
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
Re: restlet dependencies [ In reply to ]
> Let's support the single file upload feature
+1, but let this behave exactly as a zip file with a single file in it
(regarding trusted/untrusted). We just need to change the configset handler
to be able to handle non-zip files, and have a way to "locate" that file
inside the configset (in case it needs to go somewhere other than the root).

On Wed, Sep 30, 2020 at 8:45 AM Eric Pugh <epugh@opensourceconnections.com>
wrote:

> I think that me in “violent agreement” with you. Let’s understand the
> Annotations approach that we have, or pick something that is commonly used
> like JAX-RS / Jersey.
>
>
>
> On Sep 30, 2020, at 11:41 AM, Timothy Potter <thelabdude@gmail.com> wrote:
>
> I'm sorry, I don't understand what you mean by "make it a single pattern
> (the annotations?)" Eric?
>
> To me, the pattern is well established in the Java world: JAX-RS (with
> Jersey as the underlying impl. which has nice integration with Jetty). But
> when I suggested porting the code that uses restlet to JAX-RS / Jersey,
> Ishan said that wasn't necessary and is already supported with some
> Annotations ... I have no idea what that means and need more info about
> what is already in place. Short of that, replacing restlet with JAX-RS /
> Jersey looks like a trivial amount of work to me (and I'm happy to take it
> on).
>
> Tim
>
> On Wed, Sep 30, 2020 at 9:36 AM Eric Pugh <epugh@opensourceconnections.com>
> wrote:
>
>> The use case of “I want to update something via a API” is I think pretty
>> common, and it would be nice to make it a single pattern (the annotations?)
>> with lots of examples/developer docs for the next person.
>>
>>
>>
>> On Sep 30, 2020, at 11:04 AM, Timothy Potter <thelabdude@gmail.com>
>> wrote:
>>
>> I started looking into removing Managed Resources in master and wanted to
>> mention that the LTR contrib also relies on this framework
>> (ManagedModelStore and ManagedFeatureStore, see:
>> https://lucene.apache.org/solr/guide/8_6/learning-to-rank.html#uploading-a-model).
>> I only mention this b/c it's been said several times in this thread that
>> nobody uses this feature and it's only for editing config/schema like
>> synonyms. Afaik, LTR is a broadly used feature of Solr so now I'm not so
>> bullish on removing the ability to manage dynamic resources using a REST
>> like API. I agree that changing resources like the synonym set could be
>> replaced with configSet updates but I don't see how to replace the RESTful
>> model / feature store API w/o something like Managed Resources?
>>
>> From where I sit, I think we should just remove the use of restlet in the
>> implementation but keep the API for Solr 9 (master).
>>
>> @Ishan ~ you mentioned there is a way to get REST API like behavior w/o
>> using JAX-RS / Jersey ... something about annotations? Can you point me to
>> some example code of how that is done please?
>>
>> Cheers,
>> Tim
>>
>> On Wed, Sep 30, 2020 at 8:29 AM David Smiley <dsmiley@apache.org> wrote:
>>
>>> These resources are fundamentally a part of the configSet and can (in
>>> general) affect query results and thus flushing caches (via a reload) is
>>> appropriate.
>>>
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley
>>>
>>>
>>> On Wed, Sep 30, 2020 at 9:06 AM Noble Paul <noble.paul@gmail.com> wrote:
>>>
>>>> Well, I believe we should have a mechanism to upload a single file to
>>>> a configset.
>>>>
>>>> > A single file configset upload would require the user to reload the
>>>> collection, so it isn't better than managed resources.
>>>>
>>>> This is not true
>>>>
>>>> Only config/schema file changes result in core reload.
>>>>
>>>> On Wed, Sep 30, 2020 at 10:23 PM David Smiley <dsmiley@apache.org>
>>>> wrote:
>>>> >
>>>> > Definitely don't remove in 8.x!
>>>> >
>>>> > > A single file configset upload would require the user to reload
>>>> the collection, so it isn't better than managed resources.
>>>> >
>>>> > Do you view that as a substantial point in favor of
>>>> managed-resources? I view that as a trivial matter, and one I prefer to
>>>> automagic and potentially premature reload if there are additional edits to
>>>> be done (e.g. query-elevation or other word lists).
>>>> >
>>>> > ~ David Smiley
>>>> > Apache Lucene/Solr Search Developer
>>>> > http://www.linkedin.com/in/davidwsmiley
>>>> >
>>>> >
>>>> > On Wed, Sep 30, 2020 at 5:46 AM Ishan Chattopadhyaya <
>>>> ichattopadhyaya@gmail.com> wrote:
>>>> >>
>>>> >> > * Nobody knows how it works. It's unsupported
>>>> >> It is supported and documented:
>>>> https://lucene.apache.org/solr/guide/8_6/managed-resources.html
>>>> >>
>>>> >> > * RESTlet dependency
>>>> >> > * Cannot be secured using standard permissions
>>>> >> > * It's extremely complex for the functionality it offers.
>>>> >>
>>>> >> I agree. Whatever alternative we build should address these, before
>>>> we consider removing managed resources.
>>>> >>
>>>> >> On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya <
>>>> ichattopadhyaya@gmail.com> wrote:
>>>> >>>
>>>> >>> The managed resources is the only reasonable way to upload synonyms
>>>> on the fly for users today. A single file configset upload would require
>>>> the user to reload the collection, so it isn't better than managed
>>>> resources. I would not recommend we remove the functionality without first
>>>> building a suitable alternative. I agree that the feature isn't built using
>>>> proper framework or proper APIs, but it is a feature that works well.
>>>> >>>
>>>> >>> Usually, I support throwing features out even without existence of
>>>> an alternative, but I do that for non essential features. In my mind,
>>>> ability to manage synonyms elegantly is an essential feature for a search
>>>> engine.
>>>> >>>
>>>> >>> On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler, <uwe@thetaphi.de>
>>>> wrote:
>>>> >>>>
>>>> >>>> Please don't do this.
>>>> >>>>
>>>> >>>> In short: remove restlet stuff from master. Pull requests on
>>>> master are executed with Gradle on GitHub hardware.
>>>> >>>>
>>>> >>>> Ivy stuff in 8.x is built in more or less persistent servers and
>>>> there is no issue.
>>>> >>>>
>>>> >>>> What's the problem?
>>>> >>>>
>>>> >>>> Uwe
>>>> >>>>
>>>> >>>> Am September 30, 2020 8:59:06 AM UTC schrieb Ishan Chattopadhyaya <
>>>> ichattopadhyaya@gmail.com>:
>>>> >>>>>
>>>> >>>>> Can we discuss this with ASF and get an exception for this?
>>>> >>>>>
>>>> >>>>> On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, <
>>>> dawid.weiss@gmail.com> wrote:
>>>> >>>>>>
>>>> >>>>>> We can't have or redistribute binaries in ASL sources - that's
>>>> my understanding.
>>>> >>>>>>
>>>> >>>>>> Dawid
>>>> >>>>>>
>>>> >>>>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
>>>> >>>>>> <ichattopadhyaya@gmail.com> wrote:
>>>> >>>>>> >
>>>> >>>>>> > Can we pull in the jar inside our codebase?
>>>> >>>>>> >
>>>> >>>>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <
>>>> dawid.weiss@gmail.com> wrote:
>>>> >>>>>> >>
>>>> >>>>>> >>
>>>> >>>>>> >> We can upgrade if it doesn't break anything... which I can't
>>>> guarantee. ;)
>>>> >>>>>> >>
>>>> >>>>>> >> Dawid
>>>> >>>>>>
>>>> >>>>>>
>>>> ---------------------------------------------------------------------
>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>> >>>>>>
>>>> >>>>
>>>> >>>> --
>>>> >>>> Uwe Schindler
>>>> >>>> Achterdiek 19, 28357 Bremen
>>>> >>>> https://www.thetaphi.de
>>>>
>>>>
>>>>
>>>> --
>>>> -----------------------------------------------------
>>>> Noble Paul
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>>
>> _______________________
>> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
>> | http://www.opensourceconnections.com | My Free/Busy
>> <http://tinyurl.com/eric-cal>
>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>> This e-mail and all contents, including attachments, is considered to be
>> Company Confidential unless explicitly stated otherwise, regardless
>> of whether attachments are marked as such.
>>
>>
> _______________________
> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
> | http://www.opensourceconnections.com | My Free/Busy
> <http://tinyurl.com/eric-cal>
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
> This e-mail and all contents, including attachments, is considered to be
> Company Confidential unless explicitly stated otherwise, regardless
> of whether attachments are marked as such.
>
>
Re: restlet dependencies [ In reply to ]
+1 to Tomas' proposal. Created SOLR-14907
<https://issues.apache.org/jira/browse/SOLR-14907> to track the effort.

- Houston

On Wed, Sep 30, 2020 at 12:26 PM Tomás Fernández Löbbe <
tomasflobbe@gmail.com> wrote:

> > Let's support the single file upload feature
> +1, but let this behave exactly as a zip file with a single file in it
> (regarding trusted/untrusted). We just need to change the configset handler
> to be able to handle non-zip files, and have a way to "locate" that file
> inside the configset (in case it needs to go somewhere other than the root).
>
> On Wed, Sep 30, 2020 at 8:45 AM Eric Pugh <epugh@opensourceconnections.com>
> wrote:
>
>> I think that me in “violent agreement” with you. Let’s understand the
>> Annotations approach that we have, or pick something that is commonly used
>> like JAX-RS / Jersey.
>>
>>
>>
>> On Sep 30, 2020, at 11:41 AM, Timothy Potter <thelabdude@gmail.com>
>> wrote:
>>
>> I'm sorry, I don't understand what you mean by "make it a single pattern
>> (the annotations?)" Eric?
>>
>> To me, the pattern is well established in the Java world: JAX-RS (with
>> Jersey as the underlying impl. which has nice integration with Jetty). But
>> when I suggested porting the code that uses restlet to JAX-RS / Jersey,
>> Ishan said that wasn't necessary and is already supported with some
>> Annotations ... I have no idea what that means and need more info about
>> what is already in place. Short of that, replacing restlet with JAX-RS /
>> Jersey looks like a trivial amount of work to me (and I'm happy to take it
>> on).
>>
>> Tim
>>
>> On Wed, Sep 30, 2020 at 9:36 AM Eric Pugh <
>> epugh@opensourceconnections.com> wrote:
>>
>>> The use case of “I want to update something via a API” is I think pretty
>>> common, and it would be nice to make it a single pattern (the annotations?)
>>> with lots of examples/developer docs for the next person.
>>>
>>>
>>>
>>> On Sep 30, 2020, at 11:04 AM, Timothy Potter <thelabdude@gmail.com>
>>> wrote:
>>>
>>> I started looking into removing Managed Resources in master and wanted
>>> to mention that the LTR contrib also relies on this framework
>>> (ManagedModelStore and ManagedFeatureStore, see:
>>> https://lucene.apache.org/solr/guide/8_6/learning-to-rank.html#uploading-a-model).
>>> I only mention this b/c it's been said several times in this thread that
>>> nobody uses this feature and it's only for editing config/schema like
>>> synonyms. Afaik, LTR is a broadly used feature of Solr so now I'm not so
>>> bullish on removing the ability to manage dynamic resources using a REST
>>> like API. I agree that changing resources like the synonym set could be
>>> replaced with configSet updates but I don't see how to replace the RESTful
>>> model / feature store API w/o something like Managed Resources?
>>>
>>> From where I sit, I think we should just remove the use of restlet in
>>> the implementation but keep the API for Solr 9 (master).
>>>
>>> @Ishan ~ you mentioned there is a way to get REST API like behavior w/o
>>> using JAX-RS / Jersey ... something about annotations? Can you point me to
>>> some example code of how that is done please?
>>>
>>> Cheers,
>>> Tim
>>>
>>> On Wed, Sep 30, 2020 at 8:29 AM David Smiley <dsmiley@apache.org> wrote:
>>>
>>>> These resources are fundamentally a part of the configSet and can (in
>>>> general) affect query results and thus flushing caches (via a reload) is
>>>> appropriate.
>>>>
>>>> ~ David Smiley
>>>> Apache Lucene/Solr Search Developer
>>>> http://www.linkedin.com/in/davidwsmiley
>>>>
>>>>
>>>> On Wed, Sep 30, 2020 at 9:06 AM Noble Paul <noble.paul@gmail.com>
>>>> wrote:
>>>>
>>>>> Well, I believe we should have a mechanism to upload a single file to
>>>>> a configset.
>>>>>
>>>>> > A single file configset upload would require the user to reload the
>>>>> collection, so it isn't better than managed resources.
>>>>>
>>>>> This is not true
>>>>>
>>>>> Only config/schema file changes result in core reload.
>>>>>
>>>>> On Wed, Sep 30, 2020 at 10:23 PM David Smiley <dsmiley@apache.org>
>>>>> wrote:
>>>>> >
>>>>> > Definitely don't remove in 8.x!
>>>>> >
>>>>> > > A single file configset upload would require the user to reload
>>>>> the collection, so it isn't better than managed resources.
>>>>> >
>>>>> > Do you view that as a substantial point in favor of
>>>>> managed-resources? I view that as a trivial matter, and one I prefer to
>>>>> automagic and potentially premature reload if there are additional edits to
>>>>> be done (e.g. query-elevation or other word lists).
>>>>> >
>>>>> > ~ David Smiley
>>>>> > Apache Lucene/Solr Search Developer
>>>>> > http://www.linkedin.com/in/davidwsmiley
>>>>> >
>>>>> >
>>>>> > On Wed, Sep 30, 2020 at 5:46 AM Ishan Chattopadhyaya <
>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>> >>
>>>>> >> > * Nobody knows how it works. It's unsupported
>>>>> >> It is supported and documented:
>>>>> https://lucene.apache.org/solr/guide/8_6/managed-resources.html
>>>>> >>
>>>>> >> > * RESTlet dependency
>>>>> >> > * Cannot be secured using standard permissions
>>>>> >> > * It's extremely complex for the functionality it offers.
>>>>> >>
>>>>> >> I agree. Whatever alternative we build should address these, before
>>>>> we consider removing managed resources.
>>>>> >>
>>>>> >> On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya <
>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>> >>>
>>>>> >>> The managed resources is the only reasonable way to upload
>>>>> synonyms on the fly for users today. A single file configset upload would
>>>>> require the user to reload the collection, so it isn't better than managed
>>>>> resources. I would not recommend we remove the functionality without first
>>>>> building a suitable alternative. I agree that the feature isn't built using
>>>>> proper framework or proper APIs, but it is a feature that works well.
>>>>> >>>
>>>>> >>> Usually, I support throwing features out even without existence of
>>>>> an alternative, but I do that for non essential features. In my mind,
>>>>> ability to manage synonyms elegantly is an essential feature for a search
>>>>> engine.
>>>>> >>>
>>>>> >>> On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler, <uwe@thetaphi.de>
>>>>> wrote:
>>>>> >>>>
>>>>> >>>> Please don't do this.
>>>>> >>>>
>>>>> >>>> In short: remove restlet stuff from master. Pull requests on
>>>>> master are executed with Gradle on GitHub hardware.
>>>>> >>>>
>>>>> >>>> Ivy stuff in 8.x is built in more or less persistent servers and
>>>>> there is no issue.
>>>>> >>>>
>>>>> >>>> What's the problem?
>>>>> >>>>
>>>>> >>>> Uwe
>>>>> >>>>
>>>>> >>>> Am September 30, 2020 8:59:06 AM UTC schrieb Ishan Chattopadhyaya
>>>>> <ichattopadhyaya@gmail.com>:
>>>>> >>>>>
>>>>> >>>>> Can we discuss this with ASF and get an exception for this?
>>>>> >>>>>
>>>>> >>>>> On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, <
>>>>> dawid.weiss@gmail.com> wrote:
>>>>> >>>>>>
>>>>> >>>>>> We can't have or redistribute binaries in ASL sources - that's
>>>>> my understanding.
>>>>> >>>>>>
>>>>> >>>>>> Dawid
>>>>> >>>>>>
>>>>> >>>>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
>>>>> >>>>>> <ichattopadhyaya@gmail.com> wrote:
>>>>> >>>>>> >
>>>>> >>>>>> > Can we pull in the jar inside our codebase?
>>>>> >>>>>> >
>>>>> >>>>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <
>>>>> dawid.weiss@gmail.com> wrote:
>>>>> >>>>>> >>
>>>>> >>>>>> >>
>>>>> >>>>>> >> We can upgrade if it doesn't break anything... which I can't
>>>>> guarantee. ;)
>>>>> >>>>>> >>
>>>>> >>>>>> >> Dawid
>>>>> >>>>>>
>>>>> >>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>> >>>>>>
>>>>> >>>>
>>>>> >>>> --
>>>>> >>>> Uwe Schindler
>>>>> >>>> Achterdiek 19, 28357 Bremen
>>>>> >>>> https://www.thetaphi.de
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> -----------------------------------------------------
>>>>> Noble Paul
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>>
>>> _______________________
>>> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
>>> | http://www.opensourceconnections.com | My Free/Busy
>>> <http://tinyurl.com/eric-cal>
>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>>> This e-mail and all contents, including attachments, is considered to be
>>> Company Confidential unless explicitly stated otherwise, regardless
>>> of whether attachments are marked as such.
>>>
>>>
>> _______________________
>> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
>> | http://www.opensourceconnections.com | My Free/Busy
>> <http://tinyurl.com/eric-cal>
>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>> This e-mail and all contents, including attachments, is considered to be
>> Company Confidential unless explicitly stated otherwise, regardless
>> of whether attachments are marked as such.
>>
>>
Re: restlet dependencies [ In reply to ]
@Tim Potter

I tried several times to get rid of the restlet dependency & keep the
functionality as is. I failed miserably. I'm not saying this to
discourage anyone who wants to give a try. Just letting you know that
it is not as easy as it may sound

On Thu, Oct 1, 2020 at 2:42 AM Houston Putman <houstonputman@gmail.com> wrote:
>
> +1 to Tomas' proposal. Created SOLR-14907 to track the effort.
>
> - Houston
>
> On Wed, Sep 30, 2020 at 12:26 PM Tomás Fernández Löbbe <tomasflobbe@gmail.com> wrote:
>>
>> > Let's support the single file upload feature
>> +1, but let this behave exactly as a zip file with a single file in it (regarding trusted/untrusted). We just need to change the configset handler to be able to handle non-zip files, and have a way to "locate" that file inside the configset (in case it needs to go somewhere other than the root).
>>
>> On Wed, Sep 30, 2020 at 8:45 AM Eric Pugh <epugh@opensourceconnections.com> wrote:
>>>
>>> I think that me in “violent agreement” with you. Let’s understand the Annotations approach that we have, or pick something that is commonly used like JAX-RS / Jersey.
>>>
>>>
>>>
>>> On Sep 30, 2020, at 11:41 AM, Timothy Potter <thelabdude@gmail.com> wrote:
>>>
>>> I'm sorry, I don't understand what you mean by "make it a single pattern (the annotations?)" Eric?
>>>
>>> To me, the pattern is well established in the Java world: JAX-RS (with Jersey as the underlying impl. which has nice integration with Jetty). But when I suggested porting the code that uses restlet to JAX-RS / Jersey, Ishan said that wasn't necessary and is already supported with some Annotations ... I have no idea what that means and need more info about what is already in place. Short of that, replacing restlet with JAX-RS / Jersey looks like a trivial amount of work to me (and I'm happy to take it on).
>>>
>>> Tim
>>>
>>> On Wed, Sep 30, 2020 at 9:36 AM Eric Pugh <epugh@opensourceconnections.com> wrote:
>>>>
>>>> The use case of “I want to update something via a API” is I think pretty common, and it would be nice to make it a single pattern (the annotations?) with lots of examples/developer docs for the next person.
>>>>
>>>>
>>>>
>>>> On Sep 30, 2020, at 11:04 AM, Timothy Potter <thelabdude@gmail.com> wrote:
>>>>
>>>> I started looking into removing Managed Resources in master and wanted to mention that the LTR contrib also relies on this framework (ManagedModelStore and ManagedFeatureStore, see: https://lucene.apache.org/solr/guide/8_6/learning-to-rank.html#uploading-a-model). I only mention this b/c it's been said several times in this thread that nobody uses this feature and it's only for editing config/schema like synonyms. Afaik, LTR is a broadly used feature of Solr so now I'm not so bullish on removing the ability to manage dynamic resources using a REST like API. I agree that changing resources like the synonym set could be replaced with configSet updates but I don't see how to replace the RESTful model / feature store API w/o something like Managed Resources?
>>>>
>>>> From where I sit, I think we should just remove the use of restlet in the implementation but keep the API for Solr 9 (master).
>>>>
>>>> @Ishan ~ you mentioned there is a way to get REST API like behavior w/o using JAX-RS / Jersey ... something about annotations? Can you point me to some example code of how that is done please?
>>>>
>>>> Cheers,
>>>> Tim
>>>>
>>>> On Wed, Sep 30, 2020 at 8:29 AM David Smiley <dsmiley@apache.org> wrote:
>>>>>
>>>>> These resources are fundamentally a part of the configSet and can (in general) affect query results and thus flushing caches (via a reload) is appropriate.
>>>>>
>>>>> ~ David Smiley
>>>>> Apache Lucene/Solr Search Developer
>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>
>>>>>
>>>>> On Wed, Sep 30, 2020 at 9:06 AM Noble Paul <noble.paul@gmail.com> wrote:
>>>>>>
>>>>>> Well, I believe we should have a mechanism to upload a single file to
>>>>>> a configset.
>>>>>>
>>>>>> > A single file configset upload would require the user to reload the collection, so it isn't better than managed resources.
>>>>>>
>>>>>> This is not true
>>>>>>
>>>>>> Only config/schema file changes result in core reload.
>>>>>>
>>>>>> On Wed, Sep 30, 2020 at 10:23 PM David Smiley <dsmiley@apache.org> wrote:
>>>>>> >
>>>>>> > Definitely don't remove in 8.x!
>>>>>> >
>>>>>> > > A single file configset upload would require the user to reload the collection, so it isn't better than managed resources.
>>>>>> >
>>>>>> > Do you view that as a substantial point in favor of managed-resources? I view that as a trivial matter, and one I prefer to automagic and potentially premature reload if there are additional edits to be done (e.g. query-elevation or other word lists).
>>>>>> >
>>>>>> > ~ David Smiley
>>>>>> > Apache Lucene/Solr Search Developer
>>>>>> > http://www.linkedin.com/in/davidwsmiley
>>>>>> >
>>>>>> >
>>>>>> > On Wed, Sep 30, 2020 at 5:46 AM Ishan Chattopadhyaya <ichattopadhyaya@gmail.com> wrote:
>>>>>> >>
>>>>>> >> > * Nobody knows how it works. It's unsupported
>>>>>> >> It is supported and documented: https://lucene.apache.org/solr/guide/8_6/managed-resources.html
>>>>>> >>
>>>>>> >> > * RESTlet dependency
>>>>>> >> > * Cannot be secured using standard permissions
>>>>>> >> > * It's extremely complex for the functionality it offers.
>>>>>> >>
>>>>>> >> I agree. Whatever alternative we build should address these, before we consider removing managed resources.
>>>>>> >>
>>>>>> >> On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya <ichattopadhyaya@gmail.com> wrote:
>>>>>> >>>
>>>>>> >>> The managed resources is the only reasonable way to upload synonyms on the fly for users today. A single file configset upload would require the user to reload the collection, so it isn't better than managed resources. I would not recommend we remove the functionality without first building a suitable alternative. I agree that the feature isn't built using proper framework or proper APIs, but it is a feature that works well.
>>>>>> >>>
>>>>>> >>> Usually, I support throwing features out even without existence of an alternative, but I do that for non essential features. In my mind, ability to manage synonyms elegantly is an essential feature for a search engine.
>>>>>> >>>
>>>>>> >>> On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler, <uwe@thetaphi.de> wrote:
>>>>>> >>>>
>>>>>> >>>> Please don't do this.
>>>>>> >>>>
>>>>>> >>>> In short: remove restlet stuff from master. Pull requests on master are executed with Gradle on GitHub hardware.
>>>>>> >>>>
>>>>>> >>>> Ivy stuff in 8.x is built in more or less persistent servers and there is no issue.
>>>>>> >>>>
>>>>>> >>>> What's the problem?
>>>>>> >>>>
>>>>>> >>>> Uwe
>>>>>> >>>>
>>>>>> >>>> Am September 30, 2020 8:59:06 AM UTC schrieb Ishan Chattopadhyaya <ichattopadhyaya@gmail.com>:
>>>>>> >>>>>
>>>>>> >>>>> Can we discuss this with ASF and get an exception for this?
>>>>>> >>>>>
>>>>>> >>>>> On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, <dawid.weiss@gmail.com> wrote:
>>>>>> >>>>>>
>>>>>> >>>>>> We can't have or redistribute binaries in ASL sources - that's my understanding.
>>>>>> >>>>>>
>>>>>> >>>>>> Dawid
>>>>>> >>>>>>
>>>>>> >>>>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
>>>>>> >>>>>> <ichattopadhyaya@gmail.com> wrote:
>>>>>> >>>>>> >
>>>>>> >>>>>> > Can we pull in the jar inside our codebase?
>>>>>> >>>>>> >
>>>>>> >>>>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <dawid.weiss@gmail.com> wrote:
>>>>>> >>>>>> >>
>>>>>> >>>>>> >>
>>>>>> >>>>>> >> We can upgrade if it doesn't break anything... which I can't guarantee. ;)
>>>>>> >>>>>> >>
>>>>>> >>>>>> >> Dawid
>>>>>> >>>>>>
>>>>>> >>>>>> ---------------------------------------------------------------------
>>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>> >>>>>>
>>>>>> >>>>
>>>>>> >>>> --
>>>>>> >>>> Uwe Schindler
>>>>>> >>>> Achterdiek 19, 28357 Bremen
>>>>>> >>>> https://www.thetaphi.de
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> -----------------------------------------------------
>>>>>> Noble Paul
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>
>>>>
>>>> _______________________
>>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>>> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
>>>>
>>>
>>> _______________________
>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
>>>


--
-----------------------------------------------------
Noble Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: restlet dependencies [ In reply to ]
@Tim

Please check ClusterAPI or ZookeeperReadAPI etc.
Recently used it in Yasa:
https://github.com/yasa-org/yasa/blob/master/yasa-solr-plugin/src/main/java/io/github/kezhenxu94/YasaHandler.java

On Thu, Oct 1, 2020 at 10:46 AM Noble Paul <noble.paul@gmail.com> wrote:

> @Tim Potter
>
> I tried several times to get rid of the restlet dependency & keep the
> functionality as is. I failed miserably. I'm not saying this to
> discourage anyone who wants to give a try. Just letting you know that
> it is not as easy as it may sound
>
> On Thu, Oct 1, 2020 at 2:42 AM Houston Putman <houstonputman@gmail.com>
> wrote:
> >
> > +1 to Tomas' proposal. Created SOLR-14907 to track the effort.
> >
> > - Houston
> >
> > On Wed, Sep 30, 2020 at 12:26 PM Tomás Fernández Löbbe <
> tomasflobbe@gmail.com> wrote:
> >>
> >> > Let's support the single file upload feature
> >> +1, but let this behave exactly as a zip file with a single file in it
> (regarding trusted/untrusted). We just need to change the configset handler
> to be able to handle non-zip files, and have a way to "locate" that file
> inside the configset (in case it needs to go somewhere other than the root).
> >>
> >> On Wed, Sep 30, 2020 at 8:45 AM Eric Pugh <
> epugh@opensourceconnections.com> wrote:
> >>>
> >>> I think that me in “violent agreement” with you. Let’s understand
> the Annotations approach that we have, or pick something that is commonly
> used like JAX-RS / Jersey.
> >>>
> >>>
> >>>
> >>> On Sep 30, 2020, at 11:41 AM, Timothy Potter <thelabdude@gmail.com>
> wrote:
> >>>
> >>> I'm sorry, I don't understand what you mean by "make it a single
> pattern (the annotations?)" Eric?
> >>>
> >>> To me, the pattern is well established in the Java world: JAX-RS (with
> Jersey as the underlying impl. which has nice integration with Jetty). But
> when I suggested porting the code that uses restlet to JAX-RS / Jersey,
> Ishan said that wasn't necessary and is already supported with some
> Annotations ... I have no idea what that means and need more info about
> what is already in place. Short of that, replacing restlet with JAX-RS /
> Jersey looks like a trivial amount of work to me (and I'm happy to take it
> on).
> >>>
> >>> Tim
> >>>
> >>> On Wed, Sep 30, 2020 at 9:36 AM Eric Pugh <
> epugh@opensourceconnections.com> wrote:
> >>>>
> >>>> The use case of “I want to update something via a API” is I think
> pretty common, and it would be nice to make it a single pattern (the
> annotations?) with lots of examples/developer docs for the next person.
> >>>>
> >>>>
> >>>>
> >>>> On Sep 30, 2020, at 11:04 AM, Timothy Potter <thelabdude@gmail.com>
> wrote:
> >>>>
> >>>> I started looking into removing Managed Resources in master and
> wanted to mention that the LTR contrib also relies on this framework
> (ManagedModelStore and ManagedFeatureStore, see:
> https://lucene.apache.org/solr/guide/8_6/learning-to-rank.html#uploading-a-model).
> I only mention this b/c it's been said several times in this thread that
> nobody uses this feature and it's only for editing config/schema like
> synonyms. Afaik, LTR is a broadly used feature of Solr so now I'm not so
> bullish on removing the ability to manage dynamic resources using a REST
> like API. I agree that changing resources like the synonym set could be
> replaced with configSet updates but I don't see how to replace the RESTful
> model / feature store API w/o something like Managed Resources?
> >>>>
> >>>> From where I sit, I think we should just remove the use of restlet in
> the implementation but keep the API for Solr 9 (master).
> >>>>
> >>>> @Ishan ~ you mentioned there is a way to get REST API like behavior
> w/o using JAX-RS / Jersey ... something about annotations? Can you point me
> to some example code of how that is done please?
> >>>>
> >>>> Cheers,
> >>>> Tim
> >>>>
> >>>> On Wed, Sep 30, 2020 at 8:29 AM David Smiley <dsmiley@apache.org>
> wrote:
> >>>>>
> >>>>> These resources are fundamentally a part of the configSet and can
> (in general) affect query results and thus flushing caches (via a reload)
> is appropriate.
> >>>>>
> >>>>> ~ David Smiley
> >>>>> Apache Lucene/Solr Search Developer
> >>>>> http://www.linkedin.com/in/davidwsmiley
> >>>>>
> >>>>>
> >>>>> On Wed, Sep 30, 2020 at 9:06 AM Noble Paul <noble.paul@gmail.com>
> wrote:
> >>>>>>
> >>>>>> Well, I believe we should have a mechanism to upload a single file
> to
> >>>>>> a configset.
> >>>>>>
> >>>>>> > A single file configset upload would require the user to reload
> the collection, so it isn't better than managed resources.
> >>>>>>
> >>>>>> This is not true
> >>>>>>
> >>>>>> Only config/schema file changes result in core reload.
> >>>>>>
> >>>>>> On Wed, Sep 30, 2020 at 10:23 PM David Smiley <dsmiley@apache.org>
> wrote:
> >>>>>> >
> >>>>>> > Definitely don't remove in 8.x!
> >>>>>> >
> >>>>>> > > A single file configset upload would require the user to
> reload the collection, so it isn't better than managed resources.
> >>>>>> >
> >>>>>> > Do you view that as a substantial point in favor of
> managed-resources? I view that as a trivial matter, and one I prefer to
> automagic and potentially premature reload if there are additional edits to
> be done (e.g. query-elevation or other word lists).
> >>>>>> >
> >>>>>> > ~ David Smiley
> >>>>>> > Apache Lucene/Solr Search Developer
> >>>>>> > http://www.linkedin.com/in/davidwsmiley
> >>>>>> >
> >>>>>> >
> >>>>>> > On Wed, Sep 30, 2020 at 5:46 AM Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
> >>>>>> >>
> >>>>>> >> > * Nobody knows how it works. It's unsupported
> >>>>>> >> It is supported and documented:
> https://lucene.apache.org/solr/guide/8_6/managed-resources.html
> >>>>>> >>
> >>>>>> >> > * RESTlet dependency
> >>>>>> >> > * Cannot be secured using standard permissions
> >>>>>> >> > * It's extremely complex for the functionality it offers.
> >>>>>> >>
> >>>>>> >> I agree. Whatever alternative we build should address these,
> before we consider removing managed resources.
> >>>>>> >>
> >>>>>> >> On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
> >>>>>> >>>
> >>>>>> >>> The managed resources is the only reasonable way to upload
> synonyms on the fly for users today. A single file configset upload would
> require the user to reload the collection, so it isn't better than managed
> resources. I would not recommend we remove the functionality without first
> building a suitable alternative. I agree that the feature isn't built using
> proper framework or proper APIs, but it is a feature that works well.
> >>>>>> >>>
> >>>>>> >>> Usually, I support throwing features out even without existence
> of an alternative, but I do that for non essential features. In my mind,
> ability to manage synonyms elegantly is an essential feature for a search
> engine.
> >>>>>> >>>
> >>>>>> >>> On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler, <uwe@thetaphi.de>
> wrote:
> >>>>>> >>>>
> >>>>>> >>>> Please don't do this.
> >>>>>> >>>>
> >>>>>> >>>> In short: remove restlet stuff from master. Pull requests on
> master are executed with Gradle on GitHub hardware.
> >>>>>> >>>>
> >>>>>> >>>> Ivy stuff in 8.x is built in more or less persistent servers
> and there is no issue.
> >>>>>> >>>>
> >>>>>> >>>> What's the problem?
> >>>>>> >>>>
> >>>>>> >>>> Uwe
> >>>>>> >>>>
> >>>>>> >>>> Am September 30, 2020 8:59:06 AM UTC schrieb Ishan
> Chattopadhyaya <ichattopadhyaya@gmail.com>:
> >>>>>> >>>>>
> >>>>>> >>>>> Can we discuss this with ASF and get an exception for this?
> >>>>>> >>>>>
> >>>>>> >>>>> On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, <
> dawid.weiss@gmail.com> wrote:
> >>>>>> >>>>>>
> >>>>>> >>>>>> We can't have or redistribute binaries in ASL sources -
> that's my understanding.
> >>>>>> >>>>>>
> >>>>>> >>>>>> Dawid
> >>>>>> >>>>>>
> >>>>>> >>>>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
> >>>>>> >>>>>> <ichattopadhyaya@gmail.com> wrote:
> >>>>>> >>>>>> >
> >>>>>> >>>>>> > Can we pull in the jar inside our codebase?
> >>>>>> >>>>>> >
> >>>>>> >>>>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <
> dawid.weiss@gmail.com> wrote:
> >>>>>> >>>>>> >>
> >>>>>> >>>>>> >>
> >>>>>> >>>>>> >> We can upgrade if it doesn't break anything... which I
> can't guarantee. ;)
> >>>>>> >>>>>> >>
> >>>>>> >>>>>> >> Dawid
> >>>>>> >>>>>>
> >>>>>> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>>>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>>> >>>>>>
> >>>>>> >>>>
> >>>>>> >>>> --
> >>>>>> >>>> Uwe Schindler
> >>>>>> >>>> Achterdiek 19, 28357 Bremen
> >>>>>> >>>> https://www.thetaphi.de
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> -----------------------------------------------------
> >>>>>> Noble Paul
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>>>
> >>>>
> >>>> _______________________
> >>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
> 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
> >>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> >>>> This e-mail and all contents, including attachments, is considered to
> be Company Confidential unless explicitly stated otherwise, regardless of
> whether attachments are marked as such.
> >>>>
> >>>
> >>> _______________________
> >>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467
> | http://www.opensourceconnections.com | My Free/Busy
> >>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> >>> This e-mail and all contents, including attachments, is considered to
> be Company Confidential unless explicitly stated otherwise, regardless of
> whether attachments are marked as such.
> >>>
>
>
> --
> -----------------------------------------------------
> Noble Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: restlet dependencies [ In reply to ]
> But when I suggested porting the code that uses restlet to JAX-RS /
Jersey, Ishan said
> that wasn't necessary and is already supported with some Annotations ...
I have no idea
> what that means and need more info about what is already in place.

I was mainly referring to the @Endpoint annotations. It is available for V2
APIs today (and I think it should be fine to use for anything we build now
onwards, including managed resources V2).
It is possible to make it work with V1, but that will require some work.

On Thu, Oct 1, 2020 at 12:50 PM Ishan Chattopadhyaya <
ichattopadhyaya@gmail.com> wrote:

> @Tim
>
> Please check ClusterAPI or ZookeeperReadAPI etc.
> Recently used it in Yasa:
> https://github.com/yasa-org/yasa/blob/master/yasa-solr-plugin/src/main/java/io/github/kezhenxu94/YasaHandler.java
>
> On Thu, Oct 1, 2020 at 10:46 AM Noble Paul <noble.paul@gmail.com> wrote:
>
>> @Tim Potter
>>
>> I tried several times to get rid of the restlet dependency & keep the
>> functionality as is. I failed miserably. I'm not saying this to
>> discourage anyone who wants to give a try. Just letting you know that
>> it is not as easy as it may sound
>>
>> On Thu, Oct 1, 2020 at 2:42 AM Houston Putman <houstonputman@gmail.com>
>> wrote:
>> >
>> > +1 to Tomas' proposal. Created SOLR-14907 to track the effort.
>> >
>> > - Houston
>> >
>> > On Wed, Sep 30, 2020 at 12:26 PM Tomás Fernández Löbbe <
>> tomasflobbe@gmail.com> wrote:
>> >>
>> >> > Let's support the single file upload feature
>> >> +1, but let this behave exactly as a zip file with a single file in it
>> (regarding trusted/untrusted). We just need to change the configset handler
>> to be able to handle non-zip files, and have a way to "locate" that file
>> inside the configset (in case it needs to go somewhere other than the root).
>> >>
>> >> On Wed, Sep 30, 2020 at 8:45 AM Eric Pugh <
>> epugh@opensourceconnections.com> wrote:
>> >>>
>> >>> I think that me in “violent agreement” with you. Let’s understand
>> the Annotations approach that we have, or pick something that is commonly
>> used like JAX-RS / Jersey.
>> >>>
>> >>>
>> >>>
>> >>> On Sep 30, 2020, at 11:41 AM, Timothy Potter <thelabdude@gmail.com>
>> wrote:
>> >>>
>> >>> I'm sorry, I don't understand what you mean by "make it a single
>> pattern (the annotations?)" Eric?
>> >>>
>> >>> To me, the pattern is well established in the Java world: JAX-RS
>> (with Jersey as the underlying impl. which has nice integration with
>> Jetty). But when I suggested porting the code that uses restlet to JAX-RS /
>> Jersey, Ishan said that wasn't necessary and is already supported with some
>> Annotations ... I have no idea what that means and need more info about
>> what is already in place. Short of that, replacing restlet with JAX-RS /
>> Jersey looks like a trivial amount of work to me (and I'm happy to take it
>> on).
>> >>>
>> >>> Tim
>> >>>
>> >>> On Wed, Sep 30, 2020 at 9:36 AM Eric Pugh <
>> epugh@opensourceconnections.com> wrote:
>> >>>>
>> >>>> The use case of “I want to update something via a API” is I think
>> pretty common, and it would be nice to make it a single pattern (the
>> annotations?) with lots of examples/developer docs for the next person.
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Sep 30, 2020, at 11:04 AM, Timothy Potter <thelabdude@gmail.com>
>> wrote:
>> >>>>
>> >>>> I started looking into removing Managed Resources in master and
>> wanted to mention that the LTR contrib also relies on this framework
>> (ManagedModelStore and ManagedFeatureStore, see:
>> https://lucene.apache.org/solr/guide/8_6/learning-to-rank.html#uploading-a-model).
>> I only mention this b/c it's been said several times in this thread that
>> nobody uses this feature and it's only for editing config/schema like
>> synonyms. Afaik, LTR is a broadly used feature of Solr so now I'm not so
>> bullish on removing the ability to manage dynamic resources using a REST
>> like API. I agree that changing resources like the synonym set could be
>> replaced with configSet updates but I don't see how to replace the RESTful
>> model / feature store API w/o something like Managed Resources?
>> >>>>
>> >>>> From where I sit, I think we should just remove the use of restlet
>> in the implementation but keep the API for Solr 9 (master).
>> >>>>
>> >>>> @Ishan ~ you mentioned there is a way to get REST API like behavior
>> w/o using JAX-RS / Jersey ... something about annotations? Can you point me
>> to some example code of how that is done please?
>> >>>>
>> >>>> Cheers,
>> >>>> Tim
>> >>>>
>> >>>> On Wed, Sep 30, 2020 at 8:29 AM David Smiley <dsmiley@apache.org>
>> wrote:
>> >>>>>
>> >>>>> These resources are fundamentally a part of the configSet and can
>> (in general) affect query results and thus flushing caches (via a reload)
>> is appropriate.
>> >>>>>
>> >>>>> ~ David Smiley
>> >>>>> Apache Lucene/Solr Search Developer
>> >>>>> http://www.linkedin.com/in/davidwsmiley
>> >>>>>
>> >>>>>
>> >>>>> On Wed, Sep 30, 2020 at 9:06 AM Noble Paul <noble.paul@gmail.com>
>> wrote:
>> >>>>>>
>> >>>>>> Well, I believe we should have a mechanism to upload a single file
>> to
>> >>>>>> a configset.
>> >>>>>>
>> >>>>>> > A single file configset upload would require the user to reload
>> the collection, so it isn't better than managed resources.
>> >>>>>>
>> >>>>>> This is not true
>> >>>>>>
>> >>>>>> Only config/schema file changes result in core reload.
>> >>>>>>
>> >>>>>> On Wed, Sep 30, 2020 at 10:23 PM David Smiley <dsmiley@apache.org>
>> wrote:
>> >>>>>> >
>> >>>>>> > Definitely don't remove in 8.x!
>> >>>>>> >
>> >>>>>> > > A single file configset upload would require the user to
>> reload the collection, so it isn't better than managed resources.
>> >>>>>> >
>> >>>>>> > Do you view that as a substantial point in favor of
>> managed-resources? I view that as a trivial matter, and one I prefer to
>> automagic and potentially premature reload if there are additional edits to
>> be done (e.g. query-elevation or other word lists).
>> >>>>>> >
>> >>>>>> > ~ David Smiley
>> >>>>>> > Apache Lucene/Solr Search Developer
>> >>>>>> > http://www.linkedin.com/in/davidwsmiley
>> >>>>>> >
>> >>>>>> >
>> >>>>>> > On Wed, Sep 30, 2020 at 5:46 AM Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> wrote:
>> >>>>>> >>
>> >>>>>> >> > * Nobody knows how it works. It's unsupported
>> >>>>>> >> It is supported and documented:
>> https://lucene.apache.org/solr/guide/8_6/managed-resources.html
>> >>>>>> >>
>> >>>>>> >> > * RESTlet dependency
>> >>>>>> >> > * Cannot be secured using standard permissions
>> >>>>>> >> > * It's extremely complex for the functionality it offers.
>> >>>>>> >>
>> >>>>>> >> I agree. Whatever alternative we build should address these,
>> before we consider removing managed resources.
>> >>>>>> >>
>> >>>>>> >> On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> wrote:
>> >>>>>> >>>
>> >>>>>> >>> The managed resources is the only reasonable way to upload
>> synonyms on the fly for users today. A single file configset upload would
>> require the user to reload the collection, so it isn't better than managed
>> resources. I would not recommend we remove the functionality without first
>> building a suitable alternative. I agree that the feature isn't built using
>> proper framework or proper APIs, but it is a feature that works well.
>> >>>>>> >>>
>> >>>>>> >>> Usually, I support throwing features out even without
>> existence of an alternative, but I do that for non essential features. In
>> my mind, ability to manage synonyms elegantly is an essential feature for a
>> search engine.
>> >>>>>> >>>
>> >>>>>> >>> On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler, <uwe@thetaphi.de>
>> wrote:
>> >>>>>> >>>>
>> >>>>>> >>>> Please don't do this.
>> >>>>>> >>>>
>> >>>>>> >>>> In short: remove restlet stuff from master. Pull requests on
>> master are executed with Gradle on GitHub hardware.
>> >>>>>> >>>>
>> >>>>>> >>>> Ivy stuff in 8.x is built in more or less persistent servers
>> and there is no issue.
>> >>>>>> >>>>
>> >>>>>> >>>> What's the problem?
>> >>>>>> >>>>
>> >>>>>> >>>> Uwe
>> >>>>>> >>>>
>> >>>>>> >>>> Am September 30, 2020 8:59:06 AM UTC schrieb Ishan
>> Chattopadhyaya <ichattopadhyaya@gmail.com>:
>> >>>>>> >>>>>
>> >>>>>> >>>>> Can we discuss this with ASF and get an exception for this?
>> >>>>>> >>>>>
>> >>>>>> >>>>> On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, <
>> dawid.weiss@gmail.com> wrote:
>> >>>>>> >>>>>>
>> >>>>>> >>>>>> We can't have or redistribute binaries in ASL sources -
>> that's my understanding.
>> >>>>>> >>>>>>
>> >>>>>> >>>>>> Dawid
>> >>>>>> >>>>>>
>> >>>>>> >>>>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
>> >>>>>> >>>>>> <ichattopadhyaya@gmail.com> wrote:
>> >>>>>> >>>>>> >
>> >>>>>> >>>>>> > Can we pull in the jar inside our codebase?
>> >>>>>> >>>>>> >
>> >>>>>> >>>>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <
>> dawid.weiss@gmail.com> wrote:
>> >>>>>> >>>>>> >>
>> >>>>>> >>>>>> >>
>> >>>>>> >>>>>> >> We can upgrade if it doesn't break anything... which I
>> can't guarantee. ;)
>> >>>>>> >>>>>> >>
>> >>>>>> >>>>>> >> Dawid
>> >>>>>> >>>>>>
>> >>>>>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >>>>>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>>>>> >>>>>>
>> >>>>>> >>>>
>> >>>>>> >>>> --
>> >>>>>> >>>> Uwe Schindler
>> >>>>>> >>>> Achterdiek 19, 28357 Bremen
>> >>>>>> >>>> https://www.thetaphi.de
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>>>> -----------------------------------------------------
>> >>>>>> Noble Paul
>> >>>>>>
>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>>>>>
>> >>>>
>> >>>> _______________________
>> >>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
>> 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>> >>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> >>>> This e-mail and all contents, including attachments, is considered
>> to be Company Confidential unless explicitly stated otherwise, regardless
>> of whether attachments are marked as such.
>> >>>>
>> >>>
>> >>> _______________________
>> >>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
>> 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>> >>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> >>> This e-mail and all contents, including attachments, is considered to
>> be Company Confidential unless explicitly stated otherwise, regardless of
>> whether attachments are marked as such.
>> >>>
>>
>>
>> --
>> -----------------------------------------------------
>> Noble Paul
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
Re: restlet dependencies [ In reply to ]
The annotation (https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/api/EndPoint.java)
supports wild cards and templated paths

On Thu, Oct 1, 2020 at 5:28 PM Ishan Chattopadhyaya
<ichattopadhyaya@gmail.com> wrote:
>
> > But when I suggested porting the code that uses restlet to JAX-RS / Jersey, Ishan said
> > that wasn't necessary and is already supported with some Annotations ... I have no idea
> > what that means and need more info about what is already in place.
>
> I was mainly referring to the @Endpoint annotations. It is available for V2 APIs today (and I think it should be fine to use for anything we build now onwards, including managed resources V2).
> It is possible to make it work with V1, but that will require some work.
>
> On Thu, Oct 1, 2020 at 12:50 PM Ishan Chattopadhyaya <ichattopadhyaya@gmail.com> wrote:
>>
>> @Tim
>>
>> Please check ClusterAPI or ZookeeperReadAPI etc.
>> Recently used it in Yasa: https://github.com/yasa-org/yasa/blob/master/yasa-solr-plugin/src/main/java/io/github/kezhenxu94/YasaHandler.java
>>
>> On Thu, Oct 1, 2020 at 10:46 AM Noble Paul <noble.paul@gmail.com> wrote:
>>>
>>> @Tim Potter
>>>
>>> I tried several times to get rid of the restlet dependency & keep the
>>> functionality as is. I failed miserably. I'm not saying this to
>>> discourage anyone who wants to give a try. Just letting you know that
>>> it is not as easy as it may sound
>>>
>>> On Thu, Oct 1, 2020 at 2:42 AM Houston Putman <houstonputman@gmail.com> wrote:
>>> >
>>> > +1 to Tomas' proposal. Created SOLR-14907 to track the effort.
>>> >
>>> > - Houston
>>> >
>>> > On Wed, Sep 30, 2020 at 12:26 PM Tomás Fernández Löbbe <tomasflobbe@gmail.com> wrote:
>>> >>
>>> >> > Let's support the single file upload feature
>>> >> +1, but let this behave exactly as a zip file with a single file in it (regarding trusted/untrusted). We just need to change the configset handler to be able to handle non-zip files, and have a way to "locate" that file inside the configset (in case it needs to go somewhere other than the root).
>>> >>
>>> >> On Wed, Sep 30, 2020 at 8:45 AM Eric Pugh <epugh@opensourceconnections.com> wrote:
>>> >>>
>>> >>> I think that me in “violent agreement” with you. Let’s understand the Annotations approach that we have, or pick something that is commonly used like JAX-RS / Jersey.
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Sep 30, 2020, at 11:41 AM, Timothy Potter <thelabdude@gmail.com> wrote:
>>> >>>
>>> >>> I'm sorry, I don't understand what you mean by "make it a single pattern (the annotations?)" Eric?
>>> >>>
>>> >>> To me, the pattern is well established in the Java world: JAX-RS (with Jersey as the underlying impl. which has nice integration with Jetty). But when I suggested porting the code that uses restlet to JAX-RS / Jersey, Ishan said that wasn't necessary and is already supported with some Annotations ... I have no idea what that means and need more info about what is already in place. Short of that, replacing restlet with JAX-RS / Jersey looks like a trivial amount of work to me (and I'm happy to take it on).
>>> >>>
>>> >>> Tim
>>> >>>
>>> >>> On Wed, Sep 30, 2020 at 9:36 AM Eric Pugh <epugh@opensourceconnections.com> wrote:
>>> >>>>
>>> >>>> The use case of “I want to update something via a API” is I think pretty common, and it would be nice to make it a single pattern (the annotations?) with lots of examples/developer docs for the next person.
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> On Sep 30, 2020, at 11:04 AM, Timothy Potter <thelabdude@gmail.com> wrote:
>>> >>>>
>>> >>>> I started looking into removing Managed Resources in master and wanted to mention that the LTR contrib also relies on this framework (ManagedModelStore and ManagedFeatureStore, see: https://lucene.apache.org/solr/guide/8_6/learning-to-rank.html#uploading-a-model). I only mention this b/c it's been said several times in this thread that nobody uses this feature and it's only for editing config/schema like synonyms. Afaik, LTR is a broadly used feature of Solr so now I'm not so bullish on removing the ability to manage dynamic resources using a REST like API. I agree that changing resources like the synonym set could be replaced with configSet updates but I don't see how to replace the RESTful model / feature store API w/o something like Managed Resources?
>>> >>>>
>>> >>>> From where I sit, I think we should just remove the use of restlet in the implementation but keep the API for Solr 9 (master).
>>> >>>>
>>> >>>> @Ishan ~ you mentioned there is a way to get REST API like behavior w/o using JAX-RS / Jersey ... something about annotations? Can you point me to some example code of how that is done please?
>>> >>>>
>>> >>>> Cheers,
>>> >>>> Tim
>>> >>>>
>>> >>>> On Wed, Sep 30, 2020 at 8:29 AM David Smiley <dsmiley@apache.org> wrote:
>>> >>>>>
>>> >>>>> These resources are fundamentally a part of the configSet and can (in general) affect query results and thus flushing caches (via a reload) is appropriate.
>>> >>>>>
>>> >>>>> ~ David Smiley
>>> >>>>> Apache Lucene/Solr Search Developer
>>> >>>>> http://www.linkedin.com/in/davidwsmiley
>>> >>>>>
>>> >>>>>
>>> >>>>> On Wed, Sep 30, 2020 at 9:06 AM Noble Paul <noble.paul@gmail.com> wrote:
>>> >>>>>>
>>> >>>>>> Well, I believe we should have a mechanism to upload a single file to
>>> >>>>>> a configset.
>>> >>>>>>
>>> >>>>>> > A single file configset upload would require the user to reload the collection, so it isn't better than managed resources.
>>> >>>>>>
>>> >>>>>> This is not true
>>> >>>>>>
>>> >>>>>> Only config/schema file changes result in core reload.
>>> >>>>>>
>>> >>>>>> On Wed, Sep 30, 2020 at 10:23 PM David Smiley <dsmiley@apache.org> wrote:
>>> >>>>>> >
>>> >>>>>> > Definitely don't remove in 8.x!
>>> >>>>>> >
>>> >>>>>> > > A single file configset upload would require the user to reload the collection, so it isn't better than managed resources.
>>> >>>>>> >
>>> >>>>>> > Do you view that as a substantial point in favor of managed-resources? I view that as a trivial matter, and one I prefer to automagic and potentially premature reload if there are additional edits to be done (e.g. query-elevation or other word lists).
>>> >>>>>> >
>>> >>>>>> > ~ David Smiley
>>> >>>>>> > Apache Lucene/Solr Search Developer
>>> >>>>>> > http://www.linkedin.com/in/davidwsmiley
>>> >>>>>> >
>>> >>>>>> >
>>> >>>>>> > On Wed, Sep 30, 2020 at 5:46 AM Ishan Chattopadhyaya <ichattopadhyaya@gmail.com> wrote:
>>> >>>>>> >>
>>> >>>>>> >> > * Nobody knows how it works. It's unsupported
>>> >>>>>> >> It is supported and documented: https://lucene.apache.org/solr/guide/8_6/managed-resources.html
>>> >>>>>> >>
>>> >>>>>> >> > * RESTlet dependency
>>> >>>>>> >> > * Cannot be secured using standard permissions
>>> >>>>>> >> > * It's extremely complex for the functionality it offers.
>>> >>>>>> >>
>>> >>>>>> >> I agree. Whatever alternative we build should address these, before we consider removing managed resources.
>>> >>>>>> >>
>>> >>>>>> >> On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya <ichattopadhyaya@gmail.com> wrote:
>>> >>>>>> >>>
>>> >>>>>> >>> The managed resources is the only reasonable way to upload synonyms on the fly for users today. A single file configset upload would require the user to reload the collection, so it isn't better than managed resources. I would not recommend we remove the functionality without first building a suitable alternative. I agree that the feature isn't built using proper framework or proper APIs, but it is a feature that works well.
>>> >>>>>> >>>
>>> >>>>>> >>> Usually, I support throwing features out even without existence of an alternative, but I do that for non essential features. In my mind, ability to manage synonyms elegantly is an essential feature for a search engine.
>>> >>>>>> >>>
>>> >>>>>> >>> On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler, <uwe@thetaphi.de> wrote:
>>> >>>>>> >>>>
>>> >>>>>> >>>> Please don't do this.
>>> >>>>>> >>>>
>>> >>>>>> >>>> In short: remove restlet stuff from master. Pull requests on master are executed with Gradle on GitHub hardware.
>>> >>>>>> >>>>
>>> >>>>>> >>>> Ivy stuff in 8.x is built in more or less persistent servers and there is no issue.
>>> >>>>>> >>>>
>>> >>>>>> >>>> What's the problem?
>>> >>>>>> >>>>
>>> >>>>>> >>>> Uwe
>>> >>>>>> >>>>
>>> >>>>>> >>>> Am September 30, 2020 8:59:06 AM UTC schrieb Ishan Chattopadhyaya <ichattopadhyaya@gmail.com>:
>>> >>>>>> >>>>>
>>> >>>>>> >>>>> Can we discuss this with ASF and get an exception for this?
>>> >>>>>> >>>>>
>>> >>>>>> >>>>> On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, <dawid.weiss@gmail.com> wrote:
>>> >>>>>> >>>>>>
>>> >>>>>> >>>>>> We can't have or redistribute binaries in ASL sources - that's my understanding.
>>> >>>>>> >>>>>>
>>> >>>>>> >>>>>> Dawid
>>> >>>>>> >>>>>>
>>> >>>>>> >>>>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
>>> >>>>>> >>>>>> <ichattopadhyaya@gmail.com> wrote:
>>> >>>>>> >>>>>> >
>>> >>>>>> >>>>>> > Can we pull in the jar inside our codebase?
>>> >>>>>> >>>>>> >
>>> >>>>>> >>>>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <dawid.weiss@gmail.com> wrote:
>>> >>>>>> >>>>>> >>
>>> >>>>>> >>>>>> >>
>>> >>>>>> >>>>>> >> We can upgrade if it doesn't break anything... which I can't guarantee. ;)
>>> >>>>>> >>>>>> >>
>>> >>>>>> >>>>>> >> Dawid
>>> >>>>>> >>>>>>
>>> >>>>>> >>>>>> ---------------------------------------------------------------------
>>> >>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >>>>>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>>>>> >>>>>>
>>> >>>>>> >>>>
>>> >>>>>> >>>> --
>>> >>>>>> >>>> Uwe Schindler
>>> >>>>>> >>>> Achterdiek 19, 28357 Bremen
>>> >>>>>> >>>> https://www.thetaphi.de
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> --
>>> >>>>>> -----------------------------------------------------
>>> >>>>>> Noble Paul
>>> >>>>>>
>>> >>>>>> ---------------------------------------------------------------------
>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>>>>>
>>> >>>>
>>> >>>> _______________________
>>> >>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>>> >>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>> >>>> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
>>> >>>>
>>> >>>
>>> >>> _______________________
>>> >>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>>> >>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>> >>> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
>>> >>>
>>>
>>>
>>> --
>>> -----------------------------------------------------
>>> Noble Paul
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>


--
-----------------------------------------------------
Noble Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: restlet dependencies [ In reply to ]
Awesome guys, thanks for the pointers ... am cooking up a PR (for master)
for this today

On Thu, Oct 1, 2020 at 2:22 AM Noble Paul <noble.paul@gmail.com> wrote:

> The annotation (
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/api/EndPoint.java
> )
> supports wild cards and templated paths
>
> On Thu, Oct 1, 2020 at 5:28 PM Ishan Chattopadhyaya
> <ichattopadhyaya@gmail.com> wrote:
> >
> > > But when I suggested porting the code that uses restlet to JAX-RS /
> Jersey, Ishan said
> > > that wasn't necessary and is already supported with some Annotations
> ... I have no idea
> > > what that means and need more info about what is already in place.
> >
> > I was mainly referring to the @Endpoint annotations. It is available for
> V2 APIs today (and I think it should be fine to use for anything we build
> now onwards, including managed resources V2).
> > It is possible to make it work with V1, but that will require some work.
> >
> > On Thu, Oct 1, 2020 at 12:50 PM Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
> >>
> >> @Tim
> >>
> >> Please check ClusterAPI or ZookeeperReadAPI etc.
> >> Recently used it in Yasa:
> https://github.com/yasa-org/yasa/blob/master/yasa-solr-plugin/src/main/java/io/github/kezhenxu94/YasaHandler.java
> >>
> >> On Thu, Oct 1, 2020 at 10:46 AM Noble Paul <noble.paul@gmail.com>
> wrote:
> >>>
> >>> @Tim Potter
> >>>
> >>> I tried several times to get rid of the restlet dependency & keep the
> >>> functionality as is. I failed miserably. I'm not saying this to
> >>> discourage anyone who wants to give a try. Just letting you know that
> >>> it is not as easy as it may sound
> >>>
> >>> On Thu, Oct 1, 2020 at 2:42 AM Houston Putman <houstonputman@gmail.com>
> wrote:
> >>> >
> >>> > +1 to Tomas' proposal. Created SOLR-14907 to track the effort.
> >>> >
> >>> > - Houston
> >>> >
> >>> > On Wed, Sep 30, 2020 at 12:26 PM Tomás Fernández Löbbe <
> tomasflobbe@gmail.com> wrote:
> >>> >>
> >>> >> > Let's support the single file upload feature
> >>> >> +1, but let this behave exactly as a zip file with a single file in
> it (regarding trusted/untrusted). We just need to change the configset
> handler to be able to handle non-zip files, and have a way to "locate" that
> file inside the configset (in case it needs to go somewhere other than the
> root).
> >>> >>
> >>> >> On Wed, Sep 30, 2020 at 8:45 AM Eric Pugh <
> epugh@opensourceconnections.com> wrote:
> >>> >>>
> >>> >>> I think that me in “violent agreement” with you. Let’s
> understand the Annotations approach that we have, or pick something that is
> commonly used like JAX-RS / Jersey.
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> On Sep 30, 2020, at 11:41 AM, Timothy Potter <thelabdude@gmail.com>
> wrote:
> >>> >>>
> >>> >>> I'm sorry, I don't understand what you mean by "make it a single
> pattern (the annotations?)" Eric?
> >>> >>>
> >>> >>> To me, the pattern is well established in the Java world: JAX-RS
> (with Jersey as the underlying impl. which has nice integration with
> Jetty). But when I suggested porting the code that uses restlet to JAX-RS /
> Jersey, Ishan said that wasn't necessary and is already supported with some
> Annotations ... I have no idea what that means and need more info about
> what is already in place. Short of that, replacing restlet with JAX-RS /
> Jersey looks like a trivial amount of work to me (and I'm happy to take it
> on).
> >>> >>>
> >>> >>> Tim
> >>> >>>
> >>> >>> On Wed, Sep 30, 2020 at 9:36 AM Eric Pugh <
> epugh@opensourceconnections.com> wrote:
> >>> >>>>
> >>> >>>> The use case of “I want to update something via a API” is I think
> pretty common, and it would be nice to make it a single pattern (the
> annotations?) with lots of examples/developer docs for the next person.
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>> On Sep 30, 2020, at 11:04 AM, Timothy Potter <
> thelabdude@gmail.com> wrote:
> >>> >>>>
> >>> >>>> I started looking into removing Managed Resources in master and
> wanted to mention that the LTR contrib also relies on this framework
> (ManagedModelStore and ManagedFeatureStore, see:
> https://lucene.apache.org/solr/guide/8_6/learning-to-rank.html#uploading-a-model).
> I only mention this b/c it's been said several times in this thread that
> nobody uses this feature and it's only for editing config/schema like
> synonyms. Afaik, LTR is a broadly used feature of Solr so now I'm not so
> bullish on removing the ability to manage dynamic resources using a REST
> like API. I agree that changing resources like the synonym set could be
> replaced with configSet updates but I don't see how to replace the RESTful
> model / feature store API w/o something like Managed Resources?
> >>> >>>>
> >>> >>>> From where I sit, I think we should just remove the use of
> restlet in the implementation but keep the API for Solr 9 (master).
> >>> >>>>
> >>> >>>> @Ishan ~ you mentioned there is a way to get REST API like
> behavior w/o using JAX-RS / Jersey ... something about annotations? Can you
> point me to some example code of how that is done please?
> >>> >>>>
> >>> >>>> Cheers,
> >>> >>>> Tim
> >>> >>>>
> >>> >>>> On Wed, Sep 30, 2020 at 8:29 AM David Smiley <dsmiley@apache.org>
> wrote:
> >>> >>>>>
> >>> >>>>> These resources are fundamentally a part of the configSet and
> can (in general) affect query results and thus flushing caches (via a
> reload) is appropriate.
> >>> >>>>>
> >>> >>>>> ~ David Smiley
> >>> >>>>> Apache Lucene/Solr Search Developer
> >>> >>>>> http://www.linkedin.com/in/davidwsmiley
> >>> >>>>>
> >>> >>>>>
> >>> >>>>> On Wed, Sep 30, 2020 at 9:06 AM Noble Paul <noble.paul@gmail.com>
> wrote:
> >>> >>>>>>
> >>> >>>>>> Well, I believe we should have a mechanism to upload a single
> file to
> >>> >>>>>> a configset.
> >>> >>>>>>
> >>> >>>>>> > A single file configset upload would require the user to
> reload the collection, so it isn't better than managed resources.
> >>> >>>>>>
> >>> >>>>>> This is not true
> >>> >>>>>>
> >>> >>>>>> Only config/schema file changes result in core reload.
> >>> >>>>>>
> >>> >>>>>> On Wed, Sep 30, 2020 at 10:23 PM David Smiley <
> dsmiley@apache.org> wrote:
> >>> >>>>>> >
> >>> >>>>>> > Definitely don't remove in 8.x!
> >>> >>>>>> >
> >>> >>>>>> > > A single file configset upload would require the user to
> reload the collection, so it isn't better than managed resources.
> >>> >>>>>> >
> >>> >>>>>> > Do you view that as a substantial point in favor of
> managed-resources? I view that as a trivial matter, and one I prefer to
> automagic and potentially premature reload if there are additional edits to
> be done (e.g. query-elevation or other word lists).
> >>> >>>>>> >
> >>> >>>>>> > ~ David Smiley
> >>> >>>>>> > Apache Lucene/Solr Search Developer
> >>> >>>>>> > http://www.linkedin.com/in/davidwsmiley
> >>> >>>>>> >
> >>> >>>>>> >
> >>> >>>>>> > On Wed, Sep 30, 2020 at 5:46 AM Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
> >>> >>>>>> >>
> >>> >>>>>> >> > * Nobody knows how it works. It's unsupported
> >>> >>>>>> >> It is supported and documented:
> https://lucene.apache.org/solr/guide/8_6/managed-resources.html
> >>> >>>>>> >>
> >>> >>>>>> >> > * RESTlet dependency
> >>> >>>>>> >> > * Cannot be secured using standard permissions
> >>> >>>>>> >> > * It's extremely complex for the functionality it offers.
> >>> >>>>>> >>
> >>> >>>>>> >> I agree. Whatever alternative we build should address these,
> before we consider removing managed resources.
> >>> >>>>>> >>
> >>> >>>>>> >> On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
> >>> >>>>>> >>>
> >>> >>>>>> >>> The managed resources is the only reasonable way to upload
> synonyms on the fly for users today. A single file configset upload would
> require the user to reload the collection, so it isn't better than managed
> resources. I would not recommend we remove the functionality without first
> building a suitable alternative. I agree that the feature isn't built using
> proper framework or proper APIs, but it is a feature that works well.
> >>> >>>>>> >>>
> >>> >>>>>> >>> Usually, I support throwing features out even without
> existence of an alternative, but I do that for non essential features. In
> my mind, ability to manage synonyms elegantly is an essential feature for a
> search engine.
> >>> >>>>>> >>>
> >>> >>>>>> >>> On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler, <
> uwe@thetaphi.de> wrote:
> >>> >>>>>> >>>>
> >>> >>>>>> >>>> Please don't do this.
> >>> >>>>>> >>>>
> >>> >>>>>> >>>> In short: remove restlet stuff from master. Pull requests
> on master are executed with Gradle on GitHub hardware.
> >>> >>>>>> >>>>
> >>> >>>>>> >>>> Ivy stuff in 8.x is built in more or less persistent
> servers and there is no issue.
> >>> >>>>>> >>>>
> >>> >>>>>> >>>> What's the problem?
> >>> >>>>>> >>>>
> >>> >>>>>> >>>> Uwe
> >>> >>>>>> >>>>
> >>> >>>>>> >>>> Am September 30, 2020 8:59:06 AM UTC schrieb Ishan
> Chattopadhyaya <ichattopadhyaya@gmail.com>:
> >>> >>>>>> >>>>>
> >>> >>>>>> >>>>> Can we discuss this with ASF and get an exception for
> this?
> >>> >>>>>> >>>>>
> >>> >>>>>> >>>>> On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, <
> dawid.weiss@gmail.com> wrote:
> >>> >>>>>> >>>>>>
> >>> >>>>>> >>>>>> We can't have or redistribute binaries in ASL sources -
> that's my understanding.
> >>> >>>>>> >>>>>>
> >>> >>>>>> >>>>>> Dawid
> >>> >>>>>> >>>>>>
> >>> >>>>>> >>>>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
> >>> >>>>>> >>>>>> <ichattopadhyaya@gmail.com> wrote:
> >>> >>>>>> >>>>>> >
> >>> >>>>>> >>>>>> > Can we pull in the jar inside our codebase?
> >>> >>>>>> >>>>>> >
> >>> >>>>>> >>>>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <
> dawid.weiss@gmail.com> wrote:
> >>> >>>>>> >>>>>> >>
> >>> >>>>>> >>>>>> >>
> >>> >>>>>> >>>>>> >> We can upgrade if it doesn't break anything... which
> I can't guarantee. ;)
> >>> >>>>>> >>>>>> >>
> >>> >>>>>> >>>>>> >> Dawid
> >>> >>>>>> >>>>>>
> >>> >>>>>> >>>>>>
> ---------------------------------------------------------------------
> >>> >>>>>> >>>>>> To unsubscribe, e-mail:
> dev-unsubscribe@lucene.apache.org
> >>> >>>>>> >>>>>> For additional commands, e-mail:
> dev-help@lucene.apache.org
> >>> >>>>>> >>>>>>
> >>> >>>>>> >>>>
> >>> >>>>>> >>>> --
> >>> >>>>>> >>>> Uwe Schindler
> >>> >>>>>> >>>> Achterdiek 19, 28357 Bremen
> >>> >>>>>> >>>> https://www.thetaphi.de
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>> --
> >>> >>>>>> -----------------------------------------------------
> >>> >>>>>> Noble Paul
> >>> >>>>>>
> >>> >>>>>>
> ---------------------------------------------------------------------
> >>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>> >>>>>>
> >>> >>>>
> >>> >>>> _______________________
> >>> >>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
> 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
> >>> >>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> >>> >>>> This e-mail and all contents, including attachments, is
> considered to be Company Confidential unless explicitly stated otherwise,
> regardless of whether attachments are marked as such.
> >>> >>>>
> >>> >>>
> >>> >>> _______________________
> >>> >>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
> 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
> >>> >>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> >>> >>> This e-mail and all contents, including attachments, is considered
> to be Company Confidential unless explicitly stated otherwise, regardless
> of whether attachments are marked as such.
> >>> >>>
> >>>
> >>>
> >>> --
> >>> -----------------------------------------------------
> >>> Noble Paul
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>
>
>
> --
> -----------------------------------------------------
> Noble Paul
>
Re: restlet dependencies [ In reply to ]
Just want to close the loop on this restlet issue. I've removed the restlet
dependency in master (e879a52291ef7dcd0514e7419d811b6ff800bcce) but have
not backported that to 8.x yet.

I'm hesitant to backport because I had to change public function signatures
on ManagedResource, e.g.
https://github.com/apache/lucene-solr/commit/e879a52291ef7dcd0514e7419d811b6ff800bcce#diff-faaf5cd2bfe038f81ca4c0cb1986b42dR355
...

So technically, this could break upgrades for environments with extensions
to those classes; practically speaking, I think the risk of that is low,
but not sure it is worth it? From what I understand, the restlet maven
issue was mostly affecting master / gradle builds and the ant/ivy builds in
8.x weren't affected as much?

It's an easy back-port from master to 8.x if that's what we want to do, but
wanted to raise awareness that it will break public function signatures on
classes that may have extensions in the wild ;-)

~ Tim

On Thu, Oct 1, 2020 at 8:36 AM Timothy Potter <thelabdude@gmail.com> wrote:

> Awesome guys, thanks for the pointers ... am cooking up a PR (for master)
> for this today
>
> On Thu, Oct 1, 2020 at 2:22 AM Noble Paul <noble.paul@gmail.com> wrote:
>
>> The annotation (
>> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/api/EndPoint.java
>> )
>> supports wild cards and templated paths
>>
>> On Thu, Oct 1, 2020 at 5:28 PM Ishan Chattopadhyaya
>> <ichattopadhyaya@gmail.com> wrote:
>> >
>> > > But when I suggested porting the code that uses restlet to JAX-RS /
>> Jersey, Ishan said
>> > > that wasn't necessary and is already supported with some Annotations
>> ... I have no idea
>> > > what that means and need more info about what is already in place.
>> >
>> > I was mainly referring to the @Endpoint annotations. It is available
>> for V2 APIs today (and I think it should be fine to use for anything we
>> build now onwards, including managed resources V2).
>> > It is possible to make it work with V1, but that will require some work.
>> >
>> > On Thu, Oct 1, 2020 at 12:50 PM Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> wrote:
>> >>
>> >> @Tim
>> >>
>> >> Please check ClusterAPI or ZookeeperReadAPI etc.
>> >> Recently used it in Yasa:
>> https://github.com/yasa-org/yasa/blob/master/yasa-solr-plugin/src/main/java/io/github/kezhenxu94/YasaHandler.java
>> >>
>> >> On Thu, Oct 1, 2020 at 10:46 AM Noble Paul <noble.paul@gmail.com>
>> wrote:
>> >>>
>> >>> @Tim Potter
>> >>>
>> >>> I tried several times to get rid of the restlet dependency & keep the
>> >>> functionality as is. I failed miserably. I'm not saying this to
>> >>> discourage anyone who wants to give a try. Just letting you know that
>> >>> it is not as easy as it may sound
>> >>>
>> >>> On Thu, Oct 1, 2020 at 2:42 AM Houston Putman <
>> houstonputman@gmail.com> wrote:
>> >>> >
>> >>> > +1 to Tomas' proposal. Created SOLR-14907 to track the effort.
>> >>> >
>> >>> > - Houston
>> >>> >
>> >>> > On Wed, Sep 30, 2020 at 12:26 PM Tomás Fernández Löbbe <
>> tomasflobbe@gmail.com> wrote:
>> >>> >>
>> >>> >> > Let's support the single file upload feature
>> >>> >> +1, but let this behave exactly as a zip file with a single file
>> in it (regarding trusted/untrusted). We just need to change the configset
>> handler to be able to handle non-zip files, and have a way to "locate" that
>> file inside the configset (in case it needs to go somewhere other than the
>> root).
>> >>> >>
>> >>> >> On Wed, Sep 30, 2020 at 8:45 AM Eric Pugh <
>> epugh@opensourceconnections.com> wrote:
>> >>> >>>
>> >>> >>> I think that me in “violent agreement” with you. Let’s
>> understand the Annotations approach that we have, or pick something that is
>> commonly used like JAX-RS / Jersey.
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> On Sep 30, 2020, at 11:41 AM, Timothy Potter <
>> thelabdude@gmail.com> wrote:
>> >>> >>>
>> >>> >>> I'm sorry, I don't understand what you mean by "make it a single
>> pattern (the annotations?)" Eric?
>> >>> >>>
>> >>> >>> To me, the pattern is well established in the Java world: JAX-RS
>> (with Jersey as the underlying impl. which has nice integration with
>> Jetty). But when I suggested porting the code that uses restlet to JAX-RS /
>> Jersey, Ishan said that wasn't necessary and is already supported with some
>> Annotations ... I have no idea what that means and need more info about
>> what is already in place. Short of that, replacing restlet with JAX-RS /
>> Jersey looks like a trivial amount of work to me (and I'm happy to take it
>> on).
>> >>> >>>
>> >>> >>> Tim
>> >>> >>>
>> >>> >>> On Wed, Sep 30, 2020 at 9:36 AM Eric Pugh <
>> epugh@opensourceconnections.com> wrote:
>> >>> >>>>
>> >>> >>>> The use case of “I want to update something via a API” is I
>> think pretty common, and it would be nice to make it a single pattern (the
>> annotations?) with lots of examples/developer docs for the next person.
>> >>> >>>>
>> >>> >>>>
>> >>> >>>>
>> >>> >>>> On Sep 30, 2020, at 11:04 AM, Timothy Potter <
>> thelabdude@gmail.com> wrote:
>> >>> >>>>
>> >>> >>>> I started looking into removing Managed Resources in master and
>> wanted to mention that the LTR contrib also relies on this framework
>> (ManagedModelStore and ManagedFeatureStore, see:
>> https://lucene.apache.org/solr/guide/8_6/learning-to-rank.html#uploading-a-model).
>> I only mention this b/c it's been said several times in this thread that
>> nobody uses this feature and it's only for editing config/schema like
>> synonyms. Afaik, LTR is a broadly used feature of Solr so now I'm not so
>> bullish on removing the ability to manage dynamic resources using a REST
>> like API. I agree that changing resources like the synonym set could be
>> replaced with configSet updates but I don't see how to replace the RESTful
>> model / feature store API w/o something like Managed Resources?
>> >>> >>>>
>> >>> >>>> From where I sit, I think we should just remove the use of
>> restlet in the implementation but keep the API for Solr 9 (master).
>> >>> >>>>
>> >>> >>>> @Ishan ~ you mentioned there is a way to get REST API like
>> behavior w/o using JAX-RS / Jersey ... something about annotations? Can you
>> point me to some example code of how that is done please?
>> >>> >>>>
>> >>> >>>> Cheers,
>> >>> >>>> Tim
>> >>> >>>>
>> >>> >>>> On Wed, Sep 30, 2020 at 8:29 AM David Smiley <dsmiley@apache.org>
>> wrote:
>> >>> >>>>>
>> >>> >>>>> These resources are fundamentally a part of the configSet and
>> can (in general) affect query results and thus flushing caches (via a
>> reload) is appropriate.
>> >>> >>>>>
>> >>> >>>>> ~ David Smiley
>> >>> >>>>> Apache Lucene/Solr Search Developer
>> >>> >>>>> http://www.linkedin.com/in/davidwsmiley
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>> On Wed, Sep 30, 2020 at 9:06 AM Noble Paul <
>> noble.paul@gmail.com> wrote:
>> >>> >>>>>>
>> >>> >>>>>> Well, I believe we should have a mechanism to upload a single
>> file to
>> >>> >>>>>> a configset.
>> >>> >>>>>>
>> >>> >>>>>> > A single file configset upload would require the user to
>> reload the collection, so it isn't better than managed resources.
>> >>> >>>>>>
>> >>> >>>>>> This is not true
>> >>> >>>>>>
>> >>> >>>>>> Only config/schema file changes result in core reload.
>> >>> >>>>>>
>> >>> >>>>>> On Wed, Sep 30, 2020 at 10:23 PM David Smiley <
>> dsmiley@apache.org> wrote:
>> >>> >>>>>> >
>> >>> >>>>>> > Definitely don't remove in 8.x!
>> >>> >>>>>> >
>> >>> >>>>>> > > A single file configset upload would require the user to
>> reload the collection, so it isn't better than managed resources.
>> >>> >>>>>> >
>> >>> >>>>>> > Do you view that as a substantial point in favor of
>> managed-resources? I view that as a trivial matter, and one I prefer to
>> automagic and potentially premature reload if there are additional edits to
>> be done (e.g. query-elevation or other word lists).
>> >>> >>>>>> >
>> >>> >>>>>> > ~ David Smiley
>> >>> >>>>>> > Apache Lucene/Solr Search Developer
>> >>> >>>>>> > http://www.linkedin.com/in/davidwsmiley
>> >>> >>>>>> >
>> >>> >>>>>> >
>> >>> >>>>>> > On Wed, Sep 30, 2020 at 5:46 AM Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> wrote:
>> >>> >>>>>> >>
>> >>> >>>>>> >> > * Nobody knows how it works. It's unsupported
>> >>> >>>>>> >> It is supported and documented:
>> https://lucene.apache.org/solr/guide/8_6/managed-resources.html
>> >>> >>>>>> >>
>> >>> >>>>>> >> > * RESTlet dependency
>> >>> >>>>>> >> > * Cannot be secured using standard permissions
>> >>> >>>>>> >> > * It's extremely complex for the functionality it offers.
>> >>> >>>>>> >>
>> >>> >>>>>> >> I agree. Whatever alternative we build should address
>> these, before we consider removing managed resources.
>> >>> >>>>>> >>
>> >>> >>>>>> >> On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> wrote:
>> >>> >>>>>> >>>
>> >>> >>>>>> >>> The managed resources is the only reasonable way to upload
>> synonyms on the fly for users today. A single file configset upload would
>> require the user to reload the collection, so it isn't better than managed
>> resources. I would not recommend we remove the functionality without first
>> building a suitable alternative. I agree that the feature isn't built using
>> proper framework or proper APIs, but it is a feature that works well.
>> >>> >>>>>> >>>
>> >>> >>>>>> >>> Usually, I support throwing features out even without
>> existence of an alternative, but I do that for non essential features. In
>> my mind, ability to manage synonyms elegantly is an essential feature for a
>> search engine.
>> >>> >>>>>> >>>
>> >>> >>>>>> >>> On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler, <
>> uwe@thetaphi.de> wrote:
>> >>> >>>>>> >>>>
>> >>> >>>>>> >>>> Please don't do this.
>> >>> >>>>>> >>>>
>> >>> >>>>>> >>>> In short: remove restlet stuff from master. Pull requests
>> on master are executed with Gradle on GitHub hardware.
>> >>> >>>>>> >>>>
>> >>> >>>>>> >>>> Ivy stuff in 8.x is built in more or less persistent
>> servers and there is no issue.
>> >>> >>>>>> >>>>
>> >>> >>>>>> >>>> What's the problem?
>> >>> >>>>>> >>>>
>> >>> >>>>>> >>>> Uwe
>> >>> >>>>>> >>>>
>> >>> >>>>>> >>>> Am September 30, 2020 8:59:06 AM UTC schrieb Ishan
>> Chattopadhyaya <ichattopadhyaya@gmail.com>:
>> >>> >>>>>> >>>>>
>> >>> >>>>>> >>>>> Can we discuss this with ASF and get an exception for
>> this?
>> >>> >>>>>> >>>>>
>> >>> >>>>>> >>>>> On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, <
>> dawid.weiss@gmail.com> wrote:
>> >>> >>>>>> >>>>>>
>> >>> >>>>>> >>>>>> We can't have or redistribute binaries in ASL sources -
>> that's my understanding.
>> >>> >>>>>> >>>>>>
>> >>> >>>>>> >>>>>> Dawid
>> >>> >>>>>> >>>>>>
>> >>> >>>>>> >>>>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
>> >>> >>>>>> >>>>>> <ichattopadhyaya@gmail.com> wrote:
>> >>> >>>>>> >>>>>> >
>> >>> >>>>>> >>>>>> > Can we pull in the jar inside our codebase?
>> >>> >>>>>> >>>>>> >
>> >>> >>>>>> >>>>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <
>> dawid.weiss@gmail.com> wrote:
>> >>> >>>>>> >>>>>> >>
>> >>> >>>>>> >>>>>> >>
>> >>> >>>>>> >>>>>> >> We can upgrade if it doesn't break anything... which
>> I can't guarantee. ;)
>> >>> >>>>>> >>>>>> >>
>> >>> >>>>>> >>>>>> >> Dawid
>> >>> >>>>>> >>>>>>
>> >>> >>>>>> >>>>>>
>> ---------------------------------------------------------------------
>> >>> >>>>>> >>>>>> To unsubscribe, e-mail:
>> dev-unsubscribe@lucene.apache.org
>> >>> >>>>>> >>>>>> For additional commands, e-mail:
>> dev-help@lucene.apache.org
>> >>> >>>>>> >>>>>>
>> >>> >>>>>> >>>>
>> >>> >>>>>> >>>> --
>> >>> >>>>>> >>>> Uwe Schindler
>> >>> >>>>>> >>>> Achterdiek 19, 28357 Bremen
>> >>> >>>>>> >>>> https://www.thetaphi.de
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>> --
>> >>> >>>>>> -----------------------------------------------------
>> >>> >>>>>> Noble Paul
>> >>> >>>>>>
>> >>> >>>>>>
>> ---------------------------------------------------------------------
>> >>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>> >>>>>>
>> >>> >>>>
>> >>> >>>> _______________________
>> >>> >>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
>> 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>> >>> >>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> >>> >>>> This e-mail and all contents, including attachments, is
>> considered to be Company Confidential unless explicitly stated otherwise,
>> regardless of whether attachments are marked as such.
>> >>> >>>>
>> >>> >>>
>> >>> >>> _______________________
>> >>> >>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
>> 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>> >>> >>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> >>> >>> This e-mail and all contents, including attachments, is
>> considered to be Company Confidential unless explicitly stated otherwise,
>> regardless of whether attachments are marked as such.
>> >>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> -----------------------------------------------------
>> >>> Noble Paul
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>>
>>
>>
>> --
>> -----------------------------------------------------
>> Noble Paul
>>
>
Re: restlet dependencies [ In reply to ]
I think we should call that out in the changes.txt and make the changes
right away.

On Wed, Oct 7, 2020, 8:20 AM Timothy Potter <thelabdude@gmail.com> wrote:

> Just want to close the loop on this restlet issue. I've removed the
> restlet dependency in master (e879a52291ef7dcd0514e7419d811b6ff800bcce) but
> have not backported that to 8.x yet.
>
> I'm hesitant to backport because I had to change public function
> signatures on ManagedResource, e.g.
> https://github.com/apache/lucene-solr/commit/e879a52291ef7dcd0514e7419d811b6ff800bcce#diff-faaf5cd2bfe038f81ca4c0cb1986b42dR355
> ...
>
> So technically, this could break upgrades for environments with extensions
> to those classes; practically speaking, I think the risk of that is low,
> but not sure it is worth it? From what I understand, the restlet maven
> issue was mostly affecting master / gradle builds and the ant/ivy builds in
> 8.x weren't affected as much?
>
> It's an easy back-port from master to 8.x if that's what we want to do,
> but wanted to raise awareness that it will break public function signatures
> on classes that may have extensions in the wild ;-)
>
> ~ Tim
>
> On Thu, Oct 1, 2020 at 8:36 AM Timothy Potter <thelabdude@gmail.com>
> wrote:
>
>> Awesome guys, thanks for the pointers ... am cooking up a PR (for master)
>> for this today
>>
>> On Thu, Oct 1, 2020 at 2:22 AM Noble Paul <noble.paul@gmail.com> wrote:
>>
>>> The annotation (
>>> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/api/EndPoint.java
>>> )
>>> supports wild cards and templated paths
>>>
>>> On Thu, Oct 1, 2020 at 5:28 PM Ishan Chattopadhyaya
>>> <ichattopadhyaya@gmail.com> wrote:
>>> >
>>> > > But when I suggested porting the code that uses restlet to JAX-RS /
>>> Jersey, Ishan said
>>> > > that wasn't necessary and is already supported with some Annotations
>>> ... I have no idea
>>> > > what that means and need more info about what is already in place.
>>> >
>>> > I was mainly referring to the @Endpoint annotations. It is available
>>> for V2 APIs today (and I think it should be fine to use for anything we
>>> build now onwards, including managed resources V2).
>>> > It is possible to make it work with V1, but that will require some
>>> work.
>>> >
>>> > On Thu, Oct 1, 2020 at 12:50 PM Ishan Chattopadhyaya <
>>> ichattopadhyaya@gmail.com> wrote:
>>> >>
>>> >> @Tim
>>> >>
>>> >> Please check ClusterAPI or ZookeeperReadAPI etc.
>>> >> Recently used it in Yasa:
>>> https://github.com/yasa-org/yasa/blob/master/yasa-solr-plugin/src/main/java/io/github/kezhenxu94/YasaHandler.java
>>> >>
>>> >> On Thu, Oct 1, 2020 at 10:46 AM Noble Paul <noble.paul@gmail.com>
>>> wrote:
>>> >>>
>>> >>> @Tim Potter
>>> >>>
>>> >>> I tried several times to get rid of the restlet dependency & keep the
>>> >>> functionality as is. I failed miserably. I'm not saying this to
>>> >>> discourage anyone who wants to give a try. Just letting you know that
>>> >>> it is not as easy as it may sound
>>> >>>
>>> >>> On Thu, Oct 1, 2020 at 2:42 AM Houston Putman <
>>> houstonputman@gmail.com> wrote:
>>> >>> >
>>> >>> > +1 to Tomas' proposal. Created SOLR-14907 to track the effort.
>>> >>> >
>>> >>> > - Houston
>>> >>> >
>>> >>> > On Wed, Sep 30, 2020 at 12:26 PM Tomás Fernández Löbbe <
>>> tomasflobbe@gmail.com> wrote:
>>> >>> >>
>>> >>> >> > Let's support the single file upload feature
>>> >>> >> +1, but let this behave exactly as a zip file with a single file
>>> in it (regarding trusted/untrusted). We just need to change the configset
>>> handler to be able to handle non-zip files, and have a way to "locate" that
>>> file inside the configset (in case it needs to go somewhere other than the
>>> root).
>>> >>> >>
>>> >>> >> On Wed, Sep 30, 2020 at 8:45 AM Eric Pugh <
>>> epugh@opensourceconnections.com> wrote:
>>> >>> >>>
>>> >>> >>> I think that me in “violent agreement” with you. Let’s
>>> understand the Annotations approach that we have, or pick something that is
>>> commonly used like JAX-RS / Jersey.
>>> >>> >>>
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> On Sep 30, 2020, at 11:41 AM, Timothy Potter <
>>> thelabdude@gmail.com> wrote:
>>> >>> >>>
>>> >>> >>> I'm sorry, I don't understand what you mean by "make it a single
>>> pattern (the annotations?)" Eric?
>>> >>> >>>
>>> >>> >>> To me, the pattern is well established in the Java world: JAX-RS
>>> (with Jersey as the underlying impl. which has nice integration with
>>> Jetty). But when I suggested porting the code that uses restlet to JAX-RS /
>>> Jersey, Ishan said that wasn't necessary and is already supported with some
>>> Annotations ... I have no idea what that means and need more info about
>>> what is already in place. Short of that, replacing restlet with JAX-RS /
>>> Jersey looks like a trivial amount of work to me (and I'm happy to take it
>>> on).
>>> >>> >>>
>>> >>> >>> Tim
>>> >>> >>>
>>> >>> >>> On Wed, Sep 30, 2020 at 9:36 AM Eric Pugh <
>>> epugh@opensourceconnections.com> wrote:
>>> >>> >>>>
>>> >>> >>>> The use case of “I want to update something via a API” is I
>>> think pretty common, and it would be nice to make it a single pattern (the
>>> annotations?) with lots of examples/developer docs for the next person.
>>> >>> >>>>
>>> >>> >>>>
>>> >>> >>>>
>>> >>> >>>> On Sep 30, 2020, at 11:04 AM, Timothy Potter <
>>> thelabdude@gmail.com> wrote:
>>> >>> >>>>
>>> >>> >>>> I started looking into removing Managed Resources in master and
>>> wanted to mention that the LTR contrib also relies on this framework
>>> (ManagedModelStore and ManagedFeatureStore, see:
>>> https://lucene.apache.org/solr/guide/8_6/learning-to-rank.html#uploading-a-model).
>>> I only mention this b/c it's been said several times in this thread that
>>> nobody uses this feature and it's only for editing config/schema like
>>> synonyms. Afaik, LTR is a broadly used feature of Solr so now I'm not so
>>> bullish on removing the ability to manage dynamic resources using a REST
>>> like API. I agree that changing resources like the synonym set could be
>>> replaced with configSet updates but I don't see how to replace the RESTful
>>> model / feature store API w/o something like Managed Resources?
>>> >>> >>>>
>>> >>> >>>> From where I sit, I think we should just remove the use of
>>> restlet in the implementation but keep the API for Solr 9 (master).
>>> >>> >>>>
>>> >>> >>>> @Ishan ~ you mentioned there is a way to get REST API like
>>> behavior w/o using JAX-RS / Jersey ... something about annotations? Can you
>>> point me to some example code of how that is done please?
>>> >>> >>>>
>>> >>> >>>> Cheers,
>>> >>> >>>> Tim
>>> >>> >>>>
>>> >>> >>>> On Wed, Sep 30, 2020 at 8:29 AM David Smiley <
>>> dsmiley@apache.org> wrote:
>>> >>> >>>>>
>>> >>> >>>>> These resources are fundamentally a part of the configSet and
>>> can (in general) affect query results and thus flushing caches (via a
>>> reload) is appropriate.
>>> >>> >>>>>
>>> >>> >>>>> ~ David Smiley
>>> >>> >>>>> Apache Lucene/Solr Search Developer
>>> >>> >>>>> http://www.linkedin.com/in/davidwsmiley
>>> >>> >>>>>
>>> >>> >>>>>
>>> >>> >>>>> On Wed, Sep 30, 2020 at 9:06 AM Noble Paul <
>>> noble.paul@gmail.com> wrote:
>>> >>> >>>>>>
>>> >>> >>>>>> Well, I believe we should have a mechanism to upload a single
>>> file to
>>> >>> >>>>>> a configset.
>>> >>> >>>>>>
>>> >>> >>>>>> > A single file configset upload would require the user to
>>> reload the collection, so it isn't better than managed resources.
>>> >>> >>>>>>
>>> >>> >>>>>> This is not true
>>> >>> >>>>>>
>>> >>> >>>>>> Only config/schema file changes result in core reload.
>>> >>> >>>>>>
>>> >>> >>>>>> On Wed, Sep 30, 2020 at 10:23 PM David Smiley <
>>> dsmiley@apache.org> wrote:
>>> >>> >>>>>> >
>>> >>> >>>>>> > Definitely don't remove in 8.x!
>>> >>> >>>>>> >
>>> >>> >>>>>> > > A single file configset upload would require the user to
>>> reload the collection, so it isn't better than managed resources.
>>> >>> >>>>>> >
>>> >>> >>>>>> > Do you view that as a substantial point in favor of
>>> managed-resources? I view that as a trivial matter, and one I prefer to
>>> automagic and potentially premature reload if there are additional edits to
>>> be done (e.g. query-elevation or other word lists).
>>> >>> >>>>>> >
>>> >>> >>>>>> > ~ David Smiley
>>> >>> >>>>>> > Apache Lucene/Solr Search Developer
>>> >>> >>>>>> > http://www.linkedin.com/in/davidwsmiley
>>> >>> >>>>>> >
>>> >>> >>>>>> >
>>> >>> >>>>>> > On Wed, Sep 30, 2020 at 5:46 AM Ishan Chattopadhyaya <
>>> ichattopadhyaya@gmail.com> wrote:
>>> >>> >>>>>> >>
>>> >>> >>>>>> >> > * Nobody knows how it works. It's unsupported
>>> >>> >>>>>> >> It is supported and documented:
>>> https://lucene.apache.org/solr/guide/8_6/managed-resources.html
>>> >>> >>>>>> >>
>>> >>> >>>>>> >> > * RESTlet dependency
>>> >>> >>>>>> >> > * Cannot be secured using standard permissions
>>> >>> >>>>>> >> > * It's extremely complex for the functionality it offers.
>>> >>> >>>>>> >>
>>> >>> >>>>>> >> I agree. Whatever alternative we build should address
>>> these, before we consider removing managed resources.
>>> >>> >>>>>> >>
>>> >>> >>>>>> >> On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya <
>>> ichattopadhyaya@gmail.com> wrote:
>>> >>> >>>>>> >>>
>>> >>> >>>>>> >>> The managed resources is the only reasonable way to
>>> upload synonyms on the fly for users today. A single file configset upload
>>> would require the user to reload the collection, so it isn't better than
>>> managed resources. I would not recommend we remove the functionality
>>> without first building a suitable alternative. I agree that the feature
>>> isn't built using proper framework or proper APIs, but it is a feature that
>>> works well.
>>> >>> >>>>>> >>>
>>> >>> >>>>>> >>> Usually, I support throwing features out even without
>>> existence of an alternative, but I do that for non essential features. In
>>> my mind, ability to manage synonyms elegantly is an essential feature for a
>>> search engine.
>>> >>> >>>>>> >>>
>>> >>> >>>>>> >>> On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler, <
>>> uwe@thetaphi.de> wrote:
>>> >>> >>>>>> >>>>
>>> >>> >>>>>> >>>> Please don't do this.
>>> >>> >>>>>> >>>>
>>> >>> >>>>>> >>>> In short: remove restlet stuff from master. Pull
>>> requests on master are executed with Gradle on GitHub hardware.
>>> >>> >>>>>> >>>>
>>> >>> >>>>>> >>>> Ivy stuff in 8.x is built in more or less persistent
>>> servers and there is no issue.
>>> >>> >>>>>> >>>>
>>> >>> >>>>>> >>>> What's the problem?
>>> >>> >>>>>> >>>>
>>> >>> >>>>>> >>>> Uwe
>>> >>> >>>>>> >>>>
>>> >>> >>>>>> >>>> Am September 30, 2020 8:59:06 AM UTC schrieb Ishan
>>> Chattopadhyaya <ichattopadhyaya@gmail.com>:
>>> >>> >>>>>> >>>>>
>>> >>> >>>>>> >>>>> Can we discuss this with ASF and get an exception for
>>> this?
>>> >>> >>>>>> >>>>>
>>> >>> >>>>>> >>>>> On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, <
>>> dawid.weiss@gmail.com> wrote:
>>> >>> >>>>>> >>>>>>
>>> >>> >>>>>> >>>>>> We can't have or redistribute binaries in ASL sources
>>> - that's my understanding.
>>> >>> >>>>>> >>>>>>
>>> >>> >>>>>> >>>>>> Dawid
>>> >>> >>>>>> >>>>>>
>>> >>> >>>>>> >>>>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
>>> >>> >>>>>> >>>>>> <ichattopadhyaya@gmail.com> wrote:
>>> >>> >>>>>> >>>>>> >
>>> >>> >>>>>> >>>>>> > Can we pull in the jar inside our codebase?
>>> >>> >>>>>> >>>>>> >
>>> >>> >>>>>> >>>>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <
>>> dawid.weiss@gmail.com> wrote:
>>> >>> >>>>>> >>>>>> >>
>>> >>> >>>>>> >>>>>> >>
>>> >>> >>>>>> >>>>>> >> We can upgrade if it doesn't break anything...
>>> which I can't guarantee. ;)
>>> >>> >>>>>> >>>>>> >>
>>> >>> >>>>>> >>>>>> >> Dawid
>>> >>> >>>>>> >>>>>>
>>> >>> >>>>>> >>>>>>
>>> ---------------------------------------------------------------------
>>> >>> >>>>>> >>>>>> To unsubscribe, e-mail:
>>> dev-unsubscribe@lucene.apache.org
>>> >>> >>>>>> >>>>>> For additional commands, e-mail:
>>> dev-help@lucene.apache.org
>>> >>> >>>>>> >>>>>>
>>> >>> >>>>>> >>>>
>>> >>> >>>>>> >>>> --
>>> >>> >>>>>> >>>> Uwe Schindler
>>> >>> >>>>>> >>>> Achterdiek 19, 28357 Bremen
>>> >>> >>>>>> >>>> https://www.thetaphi.de
>>> >>> >>>>>>
>>> >>> >>>>>>
>>> >>> >>>>>>
>>> >>> >>>>>> --
>>> >>> >>>>>> -----------------------------------------------------
>>> >>> >>>>>> Noble Paul
>>> >>> >>>>>>
>>> >>> >>>>>>
>>> ---------------------------------------------------------------------
>>> >>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>> >>>>>>
>>> >>> >>>>
>>> >>> >>>> _______________________
>>> >>> >>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
>>> 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>>> >>> >>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>> >>> >>>> This e-mail and all contents, including attachments, is
>>> considered to be Company Confidential unless explicitly stated otherwise,
>>> regardless of whether attachments are marked as such.
>>> >>> >>>>
>>> >>> >>>
>>> >>> >>> _______________________
>>> >>> >>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
>>> 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>>> >>> >>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>> >>> >>> This e-mail and all contents, including attachments, is
>>> considered to be Company Confidential unless explicitly stated otherwise,
>>> regardless of whether attachments are marked as such.
>>> >>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> -----------------------------------------------------
>>> >>> Noble Paul
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >>> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>>
>>>
>>>
>>> --
>>> -----------------------------------------------------
>>> Noble Paul
>>>
>>
Re: restlet dependencies [ In reply to ]
No strong opinion from me. I think the back-compat concern is minor.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Tue, Oct 6, 2020 at 5:42 PM Noble Paul <noble.paul@gmail.com> wrote:

> I think we should call that out in the changes.txt and make the changes
> right away.
>
> On Wed, Oct 7, 2020, 8:20 AM Timothy Potter <thelabdude@gmail.com> wrote:
>
>> Just want to close the loop on this restlet issue. I've removed the
>> restlet dependency in master (e879a52291ef7dcd0514e7419d811b6ff800bcce) but
>> have not backported that to 8.x yet.
>>
>> I'm hesitant to backport because I had to change public function
>> signatures on ManagedResource, e.g.
>> https://github.com/apache/lucene-solr/commit/e879a52291ef7dcd0514e7419d811b6ff800bcce#diff-faaf5cd2bfe038f81ca4c0cb1986b42dR355
>> ...
>>
>> So technically, this could break upgrades for environments with
>> extensions to those classes; practically speaking, I think the risk of that
>> is low, but not sure it is worth it? From what I understand, the restlet
>> maven issue was mostly affecting master / gradle builds and the ant/ivy
>> builds in 8.x weren't affected as much?
>>
>> It's an easy back-port from master to 8.x if that's what we want to do,
>> but wanted to raise awareness that it will break public function signatures
>> on classes that may have extensions in the wild ;-)
>>
>> ~ Tim
>>
>> On Thu, Oct 1, 2020 at 8:36 AM Timothy Potter <thelabdude@gmail.com>
>> wrote:
>>
>>> Awesome guys, thanks for the pointers ... am cooking up a PR (for
>>> master) for this today
>>>
>>> On Thu, Oct 1, 2020 at 2:22 AM Noble Paul <noble.paul@gmail.com> wrote:
>>>
>>>> The annotation (
>>>> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/api/EndPoint.java
>>>> )
>>>> supports wild cards and templated paths
>>>>
>>>> On Thu, Oct 1, 2020 at 5:28 PM Ishan Chattopadhyaya
>>>> <ichattopadhyaya@gmail.com> wrote:
>>>> >
>>>> > > But when I suggested porting the code that uses restlet to JAX-RS /
>>>> Jersey, Ishan said
>>>> > > that wasn't necessary and is already supported with some
>>>> Annotations ... I have no idea
>>>> > > what that means and need more info about what is already in place.
>>>> >
>>>> > I was mainly referring to the @Endpoint annotations. It is available
>>>> for V2 APIs today (and I think it should be fine to use for anything we
>>>> build now onwards, including managed resources V2).
>>>> > It is possible to make it work with V1, but that will require some
>>>> work.
>>>> >
>>>> > On Thu, Oct 1, 2020 at 12:50 PM Ishan Chattopadhyaya <
>>>> ichattopadhyaya@gmail.com> wrote:
>>>> >>
>>>> >> @Tim
>>>> >>
>>>> >> Please check ClusterAPI or ZookeeperReadAPI etc.
>>>> >> Recently used it in Yasa:
>>>> https://github.com/yasa-org/yasa/blob/master/yasa-solr-plugin/src/main/java/io/github/kezhenxu94/YasaHandler.java
>>>> >>
>>>> >> On Thu, Oct 1, 2020 at 10:46 AM Noble Paul <noble.paul@gmail.com>
>>>> wrote:
>>>> >>>
>>>> >>> @Tim Potter
>>>> >>>
>>>> >>> I tried several times to get rid of the restlet dependency & keep
>>>> the
>>>> >>> functionality as is. I failed miserably. I'm not saying this to
>>>> >>> discourage anyone who wants to give a try. Just letting you know
>>>> that
>>>> >>> it is not as easy as it may sound
>>>> >>>
>>>> >>> On Thu, Oct 1, 2020 at 2:42 AM Houston Putman <
>>>> houstonputman@gmail.com> wrote:
>>>> >>> >
>>>> >>> > +1 to Tomas' proposal. Created SOLR-14907 to track the effort.
>>>> >>> >
>>>> >>> > - Houston
>>>> >>> >
>>>> >>> > On Wed, Sep 30, 2020 at 12:26 PM Tomás Fernández Löbbe <
>>>> tomasflobbe@gmail.com> wrote:
>>>> >>> >>
>>>> >>> >> > Let's support the single file upload feature
>>>> >>> >> +1, but let this behave exactly as a zip file with a single file
>>>> in it (regarding trusted/untrusted). We just need to change the configset
>>>> handler to be able to handle non-zip files, and have a way to "locate" that
>>>> file inside the configset (in case it needs to go somewhere other than the
>>>> root).
>>>> >>> >>
>>>> >>> >> On Wed, Sep 30, 2020 at 8:45 AM Eric Pugh <
>>>> epugh@opensourceconnections.com> wrote:
>>>> >>> >>>
>>>> >>> >>> I think that me in “violent agreement” with you. Let’s
>>>> understand the Annotations approach that we have, or pick something that is
>>>> commonly used like JAX-RS / Jersey.
>>>> >>> >>>
>>>> >>> >>>
>>>> >>> >>>
>>>> >>> >>> On Sep 30, 2020, at 11:41 AM, Timothy Potter <
>>>> thelabdude@gmail.com> wrote:
>>>> >>> >>>
>>>> >>> >>> I'm sorry, I don't understand what you mean by "make it a
>>>> single pattern (the annotations?)" Eric?
>>>> >>> >>>
>>>> >>> >>> To me, the pattern is well established in the Java world:
>>>> JAX-RS (with Jersey as the underlying impl. which has nice integration with
>>>> Jetty). But when I suggested porting the code that uses restlet to JAX-RS /
>>>> Jersey, Ishan said that wasn't necessary and is already supported with some
>>>> Annotations ... I have no idea what that means and need more info about
>>>> what is already in place. Short of that, replacing restlet with JAX-RS /
>>>> Jersey looks like a trivial amount of work to me (and I'm happy to take it
>>>> on).
>>>> >>> >>>
>>>> >>> >>> Tim
>>>> >>> >>>
>>>> >>> >>> On Wed, Sep 30, 2020 at 9:36 AM Eric Pugh <
>>>> epugh@opensourceconnections.com> wrote:
>>>> >>> >>>>
>>>> >>> >>>> The use case of “I want to update something via a API” is I
>>>> think pretty common, and it would be nice to make it a single pattern (the
>>>> annotations?) with lots of examples/developer docs for the next person.
>>>> >>> >>>>
>>>> >>> >>>>
>>>> >>> >>>>
>>>> >>> >>>> On Sep 30, 2020, at 11:04 AM, Timothy Potter <
>>>> thelabdude@gmail.com> wrote:
>>>> >>> >>>>
>>>> >>> >>>> I started looking into removing Managed Resources in master
>>>> and wanted to mention that the LTR contrib also relies on this framework
>>>> (ManagedModelStore and ManagedFeatureStore, see:
>>>> https://lucene.apache.org/solr/guide/8_6/learning-to-rank.html#uploading-a-model).
>>>> I only mention this b/c it's been said several times in this thread that
>>>> nobody uses this feature and it's only for editing config/schema like
>>>> synonyms. Afaik, LTR is a broadly used feature of Solr so now I'm not so
>>>> bullish on removing the ability to manage dynamic resources using a REST
>>>> like API. I agree that changing resources like the synonym set could be
>>>> replaced with configSet updates but I don't see how to replace the RESTful
>>>> model / feature store API w/o something like Managed Resources?
>>>> >>> >>>>
>>>> >>> >>>> From where I sit, I think we should just remove the use of
>>>> restlet in the implementation but keep the API for Solr 9 (master).
>>>> >>> >>>>
>>>> >>> >>>> @Ishan ~ you mentioned there is a way to get REST API like
>>>> behavior w/o using JAX-RS / Jersey ... something about annotations? Can you
>>>> point me to some example code of how that is done please?
>>>> >>> >>>>
>>>> >>> >>>> Cheers,
>>>> >>> >>>> Tim
>>>> >>> >>>>
>>>> >>> >>>> On Wed, Sep 30, 2020 at 8:29 AM David Smiley <
>>>> dsmiley@apache.org> wrote:
>>>> >>> >>>>>
>>>> >>> >>>>> These resources are fundamentally a part of the configSet and
>>>> can (in general) affect query results and thus flushing caches (via a
>>>> reload) is appropriate.
>>>> >>> >>>>>
>>>> >>> >>>>> ~ David Smiley
>>>> >>> >>>>> Apache Lucene/Solr Search Developer
>>>> >>> >>>>> http://www.linkedin.com/in/davidwsmiley
>>>> >>> >>>>>
>>>> >>> >>>>>
>>>> >>> >>>>> On Wed, Sep 30, 2020 at 9:06 AM Noble Paul <
>>>> noble.paul@gmail.com> wrote:
>>>> >>> >>>>>>
>>>> >>> >>>>>> Well, I believe we should have a mechanism to upload a
>>>> single file to
>>>> >>> >>>>>> a configset.
>>>> >>> >>>>>>
>>>> >>> >>>>>> > A single file configset upload would require the user to
>>>> reload the collection, so it isn't better than managed resources.
>>>> >>> >>>>>>
>>>> >>> >>>>>> This is not true
>>>> >>> >>>>>>
>>>> >>> >>>>>> Only config/schema file changes result in core reload.
>>>> >>> >>>>>>
>>>> >>> >>>>>> On Wed, Sep 30, 2020 at 10:23 PM David Smiley <
>>>> dsmiley@apache.org> wrote:
>>>> >>> >>>>>> >
>>>> >>> >>>>>> > Definitely don't remove in 8.x!
>>>> >>> >>>>>> >
>>>> >>> >>>>>> > > A single file configset upload would require the user
>>>> to reload the collection, so it isn't better than managed resources.
>>>> >>> >>>>>> >
>>>> >>> >>>>>> > Do you view that as a substantial point in favor of
>>>> managed-resources? I view that as a trivial matter, and one I prefer to
>>>> automagic and potentially premature reload if there are additional edits to
>>>> be done (e.g. query-elevation or other word lists).
>>>> >>> >>>>>> >
>>>> >>> >>>>>> > ~ David Smiley
>>>> >>> >>>>>> > Apache Lucene/Solr Search Developer
>>>> >>> >>>>>> > http://www.linkedin.com/in/davidwsmiley
>>>> >>> >>>>>> >
>>>> >>> >>>>>> >
>>>> >>> >>>>>> > On Wed, Sep 30, 2020 at 5:46 AM Ishan Chattopadhyaya <
>>>> ichattopadhyaya@gmail.com> wrote:
>>>> >>> >>>>>> >>
>>>> >>> >>>>>> >> > * Nobody knows how it works. It's unsupported
>>>> >>> >>>>>> >> It is supported and documented:
>>>> https://lucene.apache.org/solr/guide/8_6/managed-resources.html
>>>> >>> >>>>>> >>
>>>> >>> >>>>>> >> > * RESTlet dependency
>>>> >>> >>>>>> >> > * Cannot be secured using standard permissions
>>>> >>> >>>>>> >> > * It's extremely complex for the functionality it
>>>> offers.
>>>> >>> >>>>>> >>
>>>> >>> >>>>>> >> I agree. Whatever alternative we build should address
>>>> these, before we consider removing managed resources.
>>>> >>> >>>>>> >>
>>>> >>> >>>>>> >> On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya <
>>>> ichattopadhyaya@gmail.com> wrote:
>>>> >>> >>>>>> >>>
>>>> >>> >>>>>> >>> The managed resources is the only reasonable way to
>>>> upload synonyms on the fly for users today. A single file configset upload
>>>> would require the user to reload the collection, so it isn't better than
>>>> managed resources. I would not recommend we remove the functionality
>>>> without first building a suitable alternative. I agree that the feature
>>>> isn't built using proper framework or proper APIs, but it is a feature that
>>>> works well.
>>>> >>> >>>>>> >>>
>>>> >>> >>>>>> >>> Usually, I support throwing features out even without
>>>> existence of an alternative, but I do that for non essential features. In
>>>> my mind, ability to manage synonyms elegantly is an essential feature for a
>>>> search engine.
>>>> >>> >>>>>> >>>
>>>> >>> >>>>>> >>> On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler, <
>>>> uwe@thetaphi.de> wrote:
>>>> >>> >>>>>> >>>>
>>>> >>> >>>>>> >>>> Please don't do this.
>>>> >>> >>>>>> >>>>
>>>> >>> >>>>>> >>>> In short: remove restlet stuff from master. Pull
>>>> requests on master are executed with Gradle on GitHub hardware.
>>>> >>> >>>>>> >>>>
>>>> >>> >>>>>> >>>> Ivy stuff in 8.x is built in more or less persistent
>>>> servers and there is no issue.
>>>> >>> >>>>>> >>>>
>>>> >>> >>>>>> >>>> What's the problem?
>>>> >>> >>>>>> >>>>
>>>> >>> >>>>>> >>>> Uwe
>>>> >>> >>>>>> >>>>
>>>> >>> >>>>>> >>>> Am September 30, 2020 8:59:06 AM UTC schrieb Ishan
>>>> Chattopadhyaya <ichattopadhyaya@gmail.com>:
>>>> >>> >>>>>> >>>>>
>>>> >>> >>>>>> >>>>> Can we discuss this with ASF and get an exception for
>>>> this?
>>>> >>> >>>>>> >>>>>
>>>> >>> >>>>>> >>>>> On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, <
>>>> dawid.weiss@gmail.com> wrote:
>>>> >>> >>>>>> >>>>>>
>>>> >>> >>>>>> >>>>>> We can't have or redistribute binaries in ASL sources
>>>> - that's my understanding.
>>>> >>> >>>>>> >>>>>>
>>>> >>> >>>>>> >>>>>> Dawid
>>>> >>> >>>>>> >>>>>>
>>>> >>> >>>>>> >>>>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
>>>> >>> >>>>>> >>>>>> <ichattopadhyaya@gmail.com> wrote:
>>>> >>> >>>>>> >>>>>> >
>>>> >>> >>>>>> >>>>>> > Can we pull in the jar inside our codebase?
>>>> >>> >>>>>> >>>>>> >
>>>> >>> >>>>>> >>>>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <
>>>> dawid.weiss@gmail.com> wrote:
>>>> >>> >>>>>> >>>>>> >>
>>>> >>> >>>>>> >>>>>> >>
>>>> >>> >>>>>> >>>>>> >> We can upgrade if it doesn't break anything...
>>>> which I can't guarantee. ;)
>>>> >>> >>>>>> >>>>>> >>
>>>> >>> >>>>>> >>>>>> >> Dawid
>>>> >>> >>>>>> >>>>>>
>>>> >>> >>>>>> >>>>>>
>>>> ---------------------------------------------------------------------
>>>> >>> >>>>>> >>>>>> To unsubscribe, e-mail:
>>>> dev-unsubscribe@lucene.apache.org
>>>> >>> >>>>>> >>>>>> For additional commands, e-mail:
>>>> dev-help@lucene.apache.org
>>>> >>> >>>>>> >>>>>>
>>>> >>> >>>>>> >>>>
>>>> >>> >>>>>> >>>> --
>>>> >>> >>>>>> >>>> Uwe Schindler
>>>> >>> >>>>>> >>>> Achterdiek 19, 28357 Bremen
>>>> >>> >>>>>> >>>> https://www.thetaphi.de
>>>> >>> >>>>>>
>>>> >>> >>>>>>
>>>> >>> >>>>>>
>>>> >>> >>>>>> --
>>>> >>> >>>>>> -----------------------------------------------------
>>>> >>> >>>>>> Noble Paul
>>>> >>> >>>>>>
>>>> >>> >>>>>>
>>>> ---------------------------------------------------------------------
>>>> >>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> >>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>> >>> >>>>>>
>>>> >>> >>>>
>>>> >>> >>>> _______________________
>>>> >>> >>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
>>>> 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>>>> >>> >>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>>> >>> >>>> This e-mail and all contents, including attachments, is
>>>> considered to be Company Confidential unless explicitly stated otherwise,
>>>> regardless of whether attachments are marked as such.
>>>> >>> >>>>
>>>> >>> >>>
>>>> >>> >>> _______________________
>>>> >>> >>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
>>>> 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>>>> >>> >>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>>> >>> >>> This e-mail and all contents, including attachments, is
>>>> considered to be Company Confidential unless explicitly stated otherwise,
>>>> regardless of whether attachments are marked as such.
>>>> >>> >>>
>>>> >>>
>>>> >>>
>>>> >>> --
>>>> >>> -----------------------------------------------------
>>>> >>> Noble Paul
>>>> >>>
>>>> >>>
>>>> ---------------------------------------------------------------------
>>>> >>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> >>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>> >>>
>>>>
>>>>
>>>> --
>>>> -----------------------------------------------------
>>>> Noble Paul
>>>>
>>>
Re: restlet dependencies [ In reply to ]
Ok, good enough for me, thanks for feedback David and Noble, proceeding
with the cherry-picks to 8x

Tim

On Tue, Oct 6, 2020 at 8:25 PM David Smiley <dsmiley@apache.org> wrote:

> No strong opinion from me. I think the back-compat concern is minor.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Tue, Oct 6, 2020 at 5:42 PM Noble Paul <noble.paul@gmail.com> wrote:
>
>> I think we should call that out in the changes.txt and make the changes
>> right away.
>>
>> On Wed, Oct 7, 2020, 8:20 AM Timothy Potter <thelabdude@gmail.com> wrote:
>>
>>> Just want to close the loop on this restlet issue. I've removed the
>>> restlet dependency in master (e879a52291ef7dcd0514e7419d811b6ff800bcce) but
>>> have not backported that to 8.x yet.
>>>
>>> I'm hesitant to backport because I had to change public function
>>> signatures on ManagedResource, e.g.
>>> https://github.com/apache/lucene-solr/commit/e879a52291ef7dcd0514e7419d811b6ff800bcce#diff-faaf5cd2bfe038f81ca4c0cb1986b42dR355
>>> ...
>>>
>>> So technically, this could break upgrades for environments with
>>> extensions to those classes; practically speaking, I think the risk of that
>>> is low, but not sure it is worth it? From what I understand, the restlet
>>> maven issue was mostly affecting master / gradle builds and the ant/ivy
>>> builds in 8.x weren't affected as much?
>>>
>>> It's an easy back-port from master to 8.x if that's what we want to do,
>>> but wanted to raise awareness that it will break public function signatures
>>> on classes that may have extensions in the wild ;-)
>>>
>>> ~ Tim
>>>
>>> On Thu, Oct 1, 2020 at 8:36 AM Timothy Potter <thelabdude@gmail.com>
>>> wrote:
>>>
>>>> Awesome guys, thanks for the pointers ... am cooking up a PR (for
>>>> master) for this today
>>>>
>>>> On Thu, Oct 1, 2020 at 2:22 AM Noble Paul <noble.paul@gmail.com> wrote:
>>>>
>>>>> The annotation (
>>>>> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/api/EndPoint.java
>>>>> )
>>>>> supports wild cards and templated paths
>>>>>
>>>>> On Thu, Oct 1, 2020 at 5:28 PM Ishan Chattopadhyaya
>>>>> <ichattopadhyaya@gmail.com> wrote:
>>>>> >
>>>>> > > But when I suggested porting the code that uses restlet to JAX-RS
>>>>> / Jersey, Ishan said
>>>>> > > that wasn't necessary and is already supported with some
>>>>> Annotations ... I have no idea
>>>>> > > what that means and need more info about what is already in place.
>>>>> >
>>>>> > I was mainly referring to the @Endpoint annotations. It is available
>>>>> for V2 APIs today (and I think it should be fine to use for anything we
>>>>> build now onwards, including managed resources V2).
>>>>> > It is possible to make it work with V1, but that will require some
>>>>> work.
>>>>> >
>>>>> > On Thu, Oct 1, 2020 at 12:50 PM Ishan Chattopadhyaya <
>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>> >>
>>>>> >> @Tim
>>>>> >>
>>>>> >> Please check ClusterAPI or ZookeeperReadAPI etc.
>>>>> >> Recently used it in Yasa:
>>>>> https://github.com/yasa-org/yasa/blob/master/yasa-solr-plugin/src/main/java/io/github/kezhenxu94/YasaHandler.java
>>>>> >>
>>>>> >> On Thu, Oct 1, 2020 at 10:46 AM Noble Paul <noble.paul@gmail.com>
>>>>> wrote:
>>>>> >>>
>>>>> >>> @Tim Potter
>>>>> >>>
>>>>> >>> I tried several times to get rid of the restlet dependency & keep
>>>>> the
>>>>> >>> functionality as is. I failed miserably. I'm not saying this to
>>>>> >>> discourage anyone who wants to give a try. Just letting you know
>>>>> that
>>>>> >>> it is not as easy as it may sound
>>>>> >>>
>>>>> >>> On Thu, Oct 1, 2020 at 2:42 AM Houston Putman <
>>>>> houstonputman@gmail.com> wrote:
>>>>> >>> >
>>>>> >>> > +1 to Tomas' proposal. Created SOLR-14907 to track the effort.
>>>>> >>> >
>>>>> >>> > - Houston
>>>>> >>> >
>>>>> >>> > On Wed, Sep 30, 2020 at 12:26 PM Tomás Fernández Löbbe <
>>>>> tomasflobbe@gmail.com> wrote:
>>>>> >>> >>
>>>>> >>> >> > Let's support the single file upload feature
>>>>> >>> >> +1, but let this behave exactly as a zip file with a single
>>>>> file in it (regarding trusted/untrusted). We just need to change the
>>>>> configset handler to be able to handle non-zip files, and have a way to
>>>>> "locate" that file inside the configset (in case it needs to go somewhere
>>>>> other than the root).
>>>>> >>> >>
>>>>> >>> >> On Wed, Sep 30, 2020 at 8:45 AM Eric Pugh <
>>>>> epugh@opensourceconnections.com> wrote:
>>>>> >>> >>>
>>>>> >>> >>> I think that me in “violent agreement” with you. Let’s
>>>>> understand the Annotations approach that we have, or pick something that is
>>>>> commonly used like JAX-RS / Jersey.
>>>>> >>> >>>
>>>>> >>> >>>
>>>>> >>> >>>
>>>>> >>> >>> On Sep 30, 2020, at 11:41 AM, Timothy Potter <
>>>>> thelabdude@gmail.com> wrote:
>>>>> >>> >>>
>>>>> >>> >>> I'm sorry, I don't understand what you mean by "make it a
>>>>> single pattern (the annotations?)" Eric?
>>>>> >>> >>>
>>>>> >>> >>> To me, the pattern is well established in the Java world:
>>>>> JAX-RS (with Jersey as the underlying impl. which has nice integration with
>>>>> Jetty). But when I suggested porting the code that uses restlet to JAX-RS /
>>>>> Jersey, Ishan said that wasn't necessary and is already supported with some
>>>>> Annotations ... I have no idea what that means and need more info about
>>>>> what is already in place. Short of that, replacing restlet with JAX-RS /
>>>>> Jersey looks like a trivial amount of work to me (and I'm happy to take it
>>>>> on).
>>>>> >>> >>>
>>>>> >>> >>> Tim
>>>>> >>> >>>
>>>>> >>> >>> On Wed, Sep 30, 2020 at 9:36 AM Eric Pugh <
>>>>> epugh@opensourceconnections.com> wrote:
>>>>> >>> >>>>
>>>>> >>> >>>> The use case of “I want to update something via a API” is I
>>>>> think pretty common, and it would be nice to make it a single pattern (the
>>>>> annotations?) with lots of examples/developer docs for the next person.
>>>>> >>> >>>>
>>>>> >>> >>>>
>>>>> >>> >>>>
>>>>> >>> >>>> On Sep 30, 2020, at 11:04 AM, Timothy Potter <
>>>>> thelabdude@gmail.com> wrote:
>>>>> >>> >>>>
>>>>> >>> >>>> I started looking into removing Managed Resources in master
>>>>> and wanted to mention that the LTR contrib also relies on this framework
>>>>> (ManagedModelStore and ManagedFeatureStore, see:
>>>>> https://lucene.apache.org/solr/guide/8_6/learning-to-rank.html#uploading-a-model).
>>>>> I only mention this b/c it's been said several times in this thread that
>>>>> nobody uses this feature and it's only for editing config/schema like
>>>>> synonyms. Afaik, LTR is a broadly used feature of Solr so now I'm not so
>>>>> bullish on removing the ability to manage dynamic resources using a REST
>>>>> like API. I agree that changing resources like the synonym set could be
>>>>> replaced with configSet updates but I don't see how to replace the RESTful
>>>>> model / feature store API w/o something like Managed Resources?
>>>>> >>> >>>>
>>>>> >>> >>>> From where I sit, I think we should just remove the use of
>>>>> restlet in the implementation but keep the API for Solr 9 (master).
>>>>> >>> >>>>
>>>>> >>> >>>> @Ishan ~ you mentioned there is a way to get REST API like
>>>>> behavior w/o using JAX-RS / Jersey ... something about annotations? Can you
>>>>> point me to some example code of how that is done please?
>>>>> >>> >>>>
>>>>> >>> >>>> Cheers,
>>>>> >>> >>>> Tim
>>>>> >>> >>>>
>>>>> >>> >>>> On Wed, Sep 30, 2020 at 8:29 AM David Smiley <
>>>>> dsmiley@apache.org> wrote:
>>>>> >>> >>>>>
>>>>> >>> >>>>> These resources are fundamentally a part of the configSet
>>>>> and can (in general) affect query results and thus flushing caches (via a
>>>>> reload) is appropriate.
>>>>> >>> >>>>>
>>>>> >>> >>>>> ~ David Smiley
>>>>> >>> >>>>> Apache Lucene/Solr Search Developer
>>>>> >>> >>>>> http://www.linkedin.com/in/davidwsmiley
>>>>> >>> >>>>>
>>>>> >>> >>>>>
>>>>> >>> >>>>> On Wed, Sep 30, 2020 at 9:06 AM Noble Paul <
>>>>> noble.paul@gmail.com> wrote:
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> Well, I believe we should have a mechanism to upload a
>>>>> single file to
>>>>> >>> >>>>>> a configset.
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> > A single file configset upload would require the user to
>>>>> reload the collection, so it isn't better than managed resources.
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> This is not true
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> Only config/schema file changes result in core reload.
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> On Wed, Sep 30, 2020 at 10:23 PM David Smiley <
>>>>> dsmiley@apache.org> wrote:
>>>>> >>> >>>>>> >
>>>>> >>> >>>>>> > Definitely don't remove in 8.x!
>>>>> >>> >>>>>> >
>>>>> >>> >>>>>> > > A single file configset upload would require the user
>>>>> to reload the collection, so it isn't better than managed resources.
>>>>> >>> >>>>>> >
>>>>> >>> >>>>>> > Do you view that as a substantial point in favor of
>>>>> managed-resources? I view that as a trivial matter, and one I prefer to
>>>>> automagic and potentially premature reload if there are additional edits to
>>>>> be done (e.g. query-elevation or other word lists).
>>>>> >>> >>>>>> >
>>>>> >>> >>>>>> > ~ David Smiley
>>>>> >>> >>>>>> > Apache Lucene/Solr Search Developer
>>>>> >>> >>>>>> > http://www.linkedin.com/in/davidwsmiley
>>>>> >>> >>>>>> >
>>>>> >>> >>>>>> >
>>>>> >>> >>>>>> > On Wed, Sep 30, 2020 at 5:46 AM Ishan Chattopadhyaya <
>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>> >>> >>>>>> >>
>>>>> >>> >>>>>> >> > * Nobody knows how it works. It's unsupported
>>>>> >>> >>>>>> >> It is supported and documented:
>>>>> https://lucene.apache.org/solr/guide/8_6/managed-resources.html
>>>>> >>> >>>>>> >>
>>>>> >>> >>>>>> >> > * RESTlet dependency
>>>>> >>> >>>>>> >> > * Cannot be secured using standard permissions
>>>>> >>> >>>>>> >> > * It's extremely complex for the functionality it
>>>>> offers.
>>>>> >>> >>>>>> >>
>>>>> >>> >>>>>> >> I agree. Whatever alternative we build should address
>>>>> these, before we consider removing managed resources.
>>>>> >>> >>>>>> >>
>>>>> >>> >>>>>> >> On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya <
>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>> >>> >>>>>> >>>
>>>>> >>> >>>>>> >>> The managed resources is the only reasonable way to
>>>>> upload synonyms on the fly for users today. A single file configset upload
>>>>> would require the user to reload the collection, so it isn't better than
>>>>> managed resources. I would not recommend we remove the functionality
>>>>> without first building a suitable alternative. I agree that the feature
>>>>> isn't built using proper framework or proper APIs, but it is a feature that
>>>>> works well.
>>>>> >>> >>>>>> >>>
>>>>> >>> >>>>>> >>> Usually, I support throwing features out even without
>>>>> existence of an alternative, but I do that for non essential features. In
>>>>> my mind, ability to manage synonyms elegantly is an essential feature for a
>>>>> search engine.
>>>>> >>> >>>>>> >>>
>>>>> >>> >>>>>> >>> On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler, <
>>>>> uwe@thetaphi.de> wrote:
>>>>> >>> >>>>>> >>>>
>>>>> >>> >>>>>> >>>> Please don't do this.
>>>>> >>> >>>>>> >>>>
>>>>> >>> >>>>>> >>>> In short: remove restlet stuff from master. Pull
>>>>> requests on master are executed with Gradle on GitHub hardware.
>>>>> >>> >>>>>> >>>>
>>>>> >>> >>>>>> >>>> Ivy stuff in 8.x is built in more or less persistent
>>>>> servers and there is no issue.
>>>>> >>> >>>>>> >>>>
>>>>> >>> >>>>>> >>>> What's the problem?
>>>>> >>> >>>>>> >>>>
>>>>> >>> >>>>>> >>>> Uwe
>>>>> >>> >>>>>> >>>>
>>>>> >>> >>>>>> >>>> Am September 30, 2020 8:59:06 AM UTC schrieb Ishan
>>>>> Chattopadhyaya <ichattopadhyaya@gmail.com>:
>>>>> >>> >>>>>> >>>>>
>>>>> >>> >>>>>> >>>>> Can we discuss this with ASF and get an exception for
>>>>> this?
>>>>> >>> >>>>>> >>>>>
>>>>> >>> >>>>>> >>>>> On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, <
>>>>> dawid.weiss@gmail.com> wrote:
>>>>> >>> >>>>>> >>>>>>
>>>>> >>> >>>>>> >>>>>> We can't have or redistribute binaries in ASL
>>>>> sources - that's my understanding.
>>>>> >>> >>>>>> >>>>>>
>>>>> >>> >>>>>> >>>>>> Dawid
>>>>> >>> >>>>>> >>>>>>
>>>>> >>> >>>>>> >>>>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
>>>>> >>> >>>>>> >>>>>> <ichattopadhyaya@gmail.com> wrote:
>>>>> >>> >>>>>> >>>>>> >
>>>>> >>> >>>>>> >>>>>> > Can we pull in the jar inside our codebase?
>>>>> >>> >>>>>> >>>>>> >
>>>>> >>> >>>>>> >>>>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <
>>>>> dawid.weiss@gmail.com> wrote:
>>>>> >>> >>>>>> >>>>>> >>
>>>>> >>> >>>>>> >>>>>> >>
>>>>> >>> >>>>>> >>>>>> >> We can upgrade if it doesn't break anything...
>>>>> which I can't guarantee. ;)
>>>>> >>> >>>>>> >>>>>> >>
>>>>> >>> >>>>>> >>>>>> >> Dawid
>>>>> >>> >>>>>> >>>>>>
>>>>> >>> >>>>>> >>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> >>> >>>>>> >>>>>> To unsubscribe, e-mail:
>>>>> dev-unsubscribe@lucene.apache.org
>>>>> >>> >>>>>> >>>>>> For additional commands, e-mail:
>>>>> dev-help@lucene.apache.org
>>>>> >>> >>>>>> >>>>>>
>>>>> >>> >>>>>> >>>>
>>>>> >>> >>>>>> >>>> --
>>>>> >>> >>>>>> >>>> Uwe Schindler
>>>>> >>> >>>>>> >>>> Achterdiek 19, 28357 Bremen
>>>>> >>> >>>>>> >>>> https://www.thetaphi.de
>>>>> >>> >>>>>>
>>>>> >>> >>>>>>
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> --
>>>>> >>> >>>>>> -----------------------------------------------------
>>>>> >>> >>>>>> Noble Paul
>>>>> >>> >>>>>>
>>>>> >>> >>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> >>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> >>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>> >>> >>>>>>
>>>>> >>> >>>>
>>>>> >>> >>>> _______________________
>>>>> >>> >>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
>>>>> 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>>>>> >>> >>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>>>> >>> >>>> This e-mail and all contents, including attachments, is
>>>>> considered to be Company Confidential unless explicitly stated otherwise,
>>>>> regardless of whether attachments are marked as such.
>>>>> >>> >>>>
>>>>> >>> >>>
>>>>> >>> >>> _______________________
>>>>> >>> >>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
>>>>> 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>>>>> >>> >>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>>>> >>> >>> This e-mail and all contents, including attachments, is
>>>>> considered to be Company Confidential unless explicitly stated otherwise,
>>>>> regardless of whether attachments are marked as such.
>>>>> >>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> --
>>>>> >>> -----------------------------------------------------
>>>>> >>> Noble Paul
>>>>> >>>
>>>>> >>>
>>>>> ---------------------------------------------------------------------
>>>>> >>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> >>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>> >>>
>>>>>
>>>>>
>>>>> --
>>>>> -----------------------------------------------------
>>>>> Noble Paul
>>>>>
>>>>