Re: custom plugin version

[Zaccheo Bagnati]

What a newbie I am! :)
OK, I've seen methods to override: I'll give a try. I suppose that getName
output is then shown somewhere in the solr response.
Thank you again Erick for your patience.
Kind regards
Zaccheo



Il giorno lun 6 feb 2017 alle ore 17:33 Erick Erickson <
erickerick...@gmail.com> ha scritto:

> Sorry, IIRC is an acronym for "If I Recall Correctly", it's not a method
> name ;)
>
> There should be a method in the superclass (DocTransformer) that you
> can use to return information about the plugin, maybe getName or
> toString depending on your needs.
>
> Best,
> Erick
>
> On Mon, Feb 6, 2017 at 4:04 AM, Zaccheo Bagnati 
> wrote:
> > Thank you all for your answers.
> > Directory and  directive suggestions are clear.
> > Can you expand a little bit about IIRC method? I'm not so used to solr
> code
> > (and btw I'm neither an experienced java programmer).
> >
> > Il giorno ven 3 feb 2017 alle ore 19:25 Erick Erickson <
> > erickerick...@gmail.com> ha scritto:
> >
> >> The plugin itself is responsible for returning information about
> >> itself via an overridden method IIRC, so you have control over what
> >> version is reported.
> >>
> >> As for the other, a slight variant on King's process would be to put
> >> your custom jars in a different directory then used the 
> >> directive in solrconfig to explicitly load a specific jar rather than
> >> the regex. But separate directories would work as well, a matter of
> >> taste really.
> >>
> >> Best,
> >> Erick
> >>
> >> On Fri, Feb 3, 2017 at 8:21 AM, King Rhoton  wrote:
> >> > What we ended up doing was creating separate directories for each
> >> version of a plugin we had written, and in each collection's
> >> solrconfig,xml, we add the path to the specific directory we wanted that
> >> collection to use via the " >> >
> >> >> On Feb 3, 2017, at 2:40 AM, Andrea Gazzarini 
> wrote:
> >> >>
> >> >> Hi Zaccheo,
> >> >> I don't think this is possible, this is something related with the
> >> classloader behavior, and even if there's a "priority" rule in the JVM,
> I
> >> wouldn't rely on that in my application.
> >> >> That could be good in a dev environment where you can specify the
> >> "order" of the imported libraries (e.g. Eclipse), but definitely not so
> >> good outside (IMO).
> >> >>
> >> >> As far as I know, there's no a built-in way to declare the version of
> >> custom components, but you could adopt the same approach of Lucene, with
> >> something like a Version class that drives the behavior of your
> component.
> >> >> In this way you will have
> >> >>
> >> >> * always one jar (better: unique classes FQNs), so no classloader
> issues
> >> >> * a behavior that changes depending on the configuration
> >> >>
> >> >> Best,
> >> >> Andrea
> >> >>
> >> >> On 03/02/17 10:57, Zaccheo Bagnati wrote:
> >> >>> Hi all,
> >> >>> I developed a custom DocTransformer that is loaded from a .jar in
> the
> >> core
> >> >>> "lib" directory. It works but I have now a problem with versioning:
> >> >>> 1. if lib directory contains different versions of the same .jar
> which
> >> one
> >> >>> is loaded? I tried putting both myplugins-1.0.0.jar and
> >> myplugins-1.0.1.jar
> >> >>> and I noticed that the oldest one is loaded. Is there a way to force
> >> >>> specific jar version to be loaded in solrconfig?
> >> >>> 2. More in general: is it possible to expose in solr the version
> >> number for
> >> >>> custom plugins?
> >> >>> Thank you in advance
> >> >>>
> >> >>
> >> >
> >> >
> >> > -
> >> > King Rhoton, c/o Adobe, 601 Townsend, SF, CA 94103
> >> > 415-832-4480 x24480 <(415)%20832-4480> <(415)%20832-4480>
> >> > S support requests should go to search-...@adobe.com
> >> >
> >>
>

Re: custom plugin version

[Erick Erickson]

Sorry, IIRC is an acronym for "If I Recall Correctly", it's not a method name ;)

There should be a method in the superclass (DocTransformer) that you
can use to return information about the plugin, maybe getName or
toString depending on your needs.

Best,
Erick

On Mon, Feb 6, 2017 at 4:04 AM, Zaccheo Bagnati  wrote:
> Thank you all for your answers.
> Directory and  directive suggestions are clear.
> Can you expand a little bit about IIRC method? I'm not so used to solr code
> (and btw I'm neither an experienced java programmer).
>
> Il giorno ven 3 feb 2017 alle ore 19:25 Erick Erickson <
> erickerick...@gmail.com> ha scritto:
>
>> The plugin itself is responsible for returning information about
>> itself via an overridden method IIRC, so you have control over what
>> version is reported.
>>
>> As for the other, a slight variant on King's process would be to put
>> your custom jars in a different directory then used the 
>> directive in solrconfig to explicitly load a specific jar rather than
>> the regex. But separate directories would work as well, a matter of
>> taste really.
>>
>> Best,
>> Erick
>>
>> On Fri, Feb 3, 2017 at 8:21 AM, King Rhoton  wrote:
>> > What we ended up doing was creating separate directories for each
>> version of a plugin we had written, and in each collection's
>> solrconfig,xml, we add the path to the specific directory we wanted that
>> collection to use via the "> >
>> >> On Feb 3, 2017, at 2:40 AM, Andrea Gazzarini  wrote:
>> >>
>> >> Hi Zaccheo,
>> >> I don't think this is possible, this is something related with the
>> classloader behavior, and even if there's a "priority" rule in the JVM, I
>> wouldn't rely on that in my application.
>> >> That could be good in a dev environment where you can specify the
>> "order" of the imported libraries (e.g. Eclipse), but definitely not so
>> good outside (IMO).
>> >>
>> >> As far as I know, there's no a built-in way to declare the version of
>> custom components, but you could adopt the same approach of Lucene, with
>> something like a Version class that drives the behavior of your component.
>> >> In this way you will have
>> >>
>> >> * always one jar (better: unique classes FQNs), so no classloader issues
>> >> * a behavior that changes depending on the configuration
>> >>
>> >> Best,
>> >> Andrea
>> >>
>> >> On 03/02/17 10:57, Zaccheo Bagnati wrote:
>> >>> Hi all,
>> >>> I developed a custom DocTransformer that is loaded from a .jar in the
>> core
>> >>> "lib" directory. It works but I have now a problem with versioning:
>> >>> 1. if lib directory contains different versions of the same .jar which
>> one
>> >>> is loaded? I tried putting both myplugins-1.0.0.jar and
>> myplugins-1.0.1.jar
>> >>> and I noticed that the oldest one is loaded. Is there a way to force
>> >>> specific jar version to be loaded in solrconfig?
>> >>> 2. More in general: is it possible to expose in solr the version
>> number for
>> >>> custom plugins?
>> >>> Thank you in advance
>> >>>
>> >>
>> >
>> >
>> > -
>> > King Rhoton, c/o Adobe, 601 Townsend, SF, CA 94103
>> > 415-832-4480 x24480 <(415)%20832-4480>
>> > S support requests should go to search-...@adobe.com
>> >
>>

Re: custom plugin version

[Zaccheo Bagnati]

Thank you all for your answers.
Directory and  directive suggestions are clear.
Can you expand a little bit about IIRC method? I'm not so used to solr code
(and btw I'm neither an experienced java programmer).

Il giorno ven 3 feb 2017 alle ore 19:25 Erick Erickson <
erickerick...@gmail.com> ha scritto:

> The plugin itself is responsible for returning information about
> itself via an overridden method IIRC, so you have control over what
> version is reported.
>
> As for the other, a slight variant on King's process would be to put
> your custom jars in a different directory then used the 
> directive in solrconfig to explicitly load a specific jar rather than
> the regex. But separate directories would work as well, a matter of
> taste really.
>
> Best,
> Erick
>
> On Fri, Feb 3, 2017 at 8:21 AM, King Rhoton  wrote:
> > What we ended up doing was creating separate directories for each
> version of a plugin we had written, and in each collection's
> solrconfig,xml, we add the path to the specific directory we wanted that
> collection to use via the " >
> >> On Feb 3, 2017, at 2:40 AM, Andrea Gazzarini  wrote:
> >>
> >> Hi Zaccheo,
> >> I don't think this is possible, this is something related with the
> classloader behavior, and even if there's a "priority" rule in the JVM, I
> wouldn't rely on that in my application.
> >> That could be good in a dev environment where you can specify the
> "order" of the imported libraries (e.g. Eclipse), but definitely not so
> good outside (IMO).
> >>
> >> As far as I know, there's no a built-in way to declare the version of
> custom components, but you could adopt the same approach of Lucene, with
> something like a Version class that drives the behavior of your component.
> >> In this way you will have
> >>
> >> * always one jar (better: unique classes FQNs), so no classloader issues
> >> * a behavior that changes depending on the configuration
> >>
> >> Best,
> >> Andrea
> >>
> >> On 03/02/17 10:57, Zaccheo Bagnati wrote:
> >>> Hi all,
> >>> I developed a custom DocTransformer that is loaded from a .jar in the
> core
> >>> "lib" directory. It works but I have now a problem with versioning:
> >>> 1. if lib directory contains different versions of the same .jar which
> one
> >>> is loaded? I tried putting both myplugins-1.0.0.jar and
> myplugins-1.0.1.jar
> >>> and I noticed that the oldest one is loaded. Is there a way to force
> >>> specific jar version to be loaded in solrconfig?
> >>> 2. More in general: is it possible to expose in solr the version
> number for
> >>> custom plugins?
> >>> Thank you in advance
> >>>
> >>
> >
> >
> > -
> > King Rhoton, c/o Adobe, 601 Townsend, SF, CA 94103
> > 415-832-4480 x24480 <(415)%20832-4480>
> > S support requests should go to search-...@adobe.com
> >
>

Re: custom plugin version

[Erick Erickson]

The plugin itself is responsible for returning information about
itself via an overridden method IIRC, so you have control over what
version is reported.

As for the other, a slight variant on King's process would be to put
your custom jars in a different directory then used the 
directive in solrconfig to explicitly load a specific jar rather than
the regex. But separate directories would work as well, a matter of
taste really.

Best,
Erick

On Fri, Feb 3, 2017 at 8:21 AM, King Rhoton  wrote:
> What we ended up doing was creating separate directories for each version of 
> a plugin we had written, and in each collection's solrconfig,xml, we add the 
> path to the specific directory we wanted that collection to use via the " dir=..." tag.
>
>> On Feb 3, 2017, at 2:40 AM, Andrea Gazzarini  wrote:
>>
>> Hi Zaccheo,
>> I don't think this is possible, this is something related with the 
>> classloader behavior, and even if there's a "priority" rule in the JVM, I 
>> wouldn't rely on that in my application.
>> That could be good in a dev environment where you can specify the "order" of 
>> the imported libraries (e.g. Eclipse), but definitely not so good outside 
>> (IMO).
>>
>> As far as I know, there's no a built-in way to declare the version of custom 
>> components, but you could adopt the same approach of Lucene, with something 
>> like a Version class that drives the behavior of your component.
>> In this way you will have
>>
>> * always one jar (better: unique classes FQNs), so no classloader issues
>> * a behavior that changes depending on the configuration
>>
>> Best,
>> Andrea
>>
>> On 03/02/17 10:57, Zaccheo Bagnati wrote:
>>> Hi all,
>>> I developed a custom DocTransformer that is loaded from a .jar in the core
>>> "lib" directory. It works but I have now a problem with versioning:
>>> 1. if lib directory contains different versions of the same .jar which one
>>> is loaded? I tried putting both myplugins-1.0.0.jar and myplugins-1.0.1.jar
>>> and I noticed that the oldest one is loaded. Is there a way to force
>>> specific jar version to be loaded in solrconfig?
>>> 2. More in general: is it possible to expose in solr the version number for
>>> custom plugins?
>>> Thank you in advance
>>>
>>
>
>
> -
> King Rhoton, c/o Adobe, 601 Townsend, SF, CA 94103
> 415-832-4480 x24480
> S support requests should go to search-...@adobe.com
>

Re: custom plugin version

[King Rhoton]

What we ended up doing was creating separate directories for each version of a 
plugin we had written, and in each collection's solrconfig,xml, we add the path 
to the specific directory we wanted that collection to use via the " On Feb 3, 2017, at 2:40 AM, Andrea Gazzarini  wrote:
> 
> Hi Zaccheo,
> I don't think this is possible, this is something related with the 
> classloader behavior, and even if there's a "priority" rule in the JVM, I 
> wouldn't rely on that in my application.
> That could be good in a dev environment where you can specify the "order" of 
> the imported libraries (e.g. Eclipse), but definitely not so good outside 
> (IMO).
> 
> As far as I know, there's no a built-in way to declare the version of custom 
> components, but you could adopt the same approach of Lucene, with something 
> like a Version class that drives the behavior of your component.
> In this way you will have
> 
> * always one jar (better: unique classes FQNs), so no classloader issues
> * a behavior that changes depending on the configuration
> 
> Best,
> Andrea
> 
> On 03/02/17 10:57, Zaccheo Bagnati wrote:
>> Hi all,
>> I developed a custom DocTransformer that is loaded from a .jar in the core
>> "lib" directory. It works but I have now a problem with versioning:
>> 1. if lib directory contains different versions of the same .jar which one
>> is loaded? I tried putting both myplugins-1.0.0.jar and myplugins-1.0.1.jar
>> and I noticed that the oldest one is loaded. Is there a way to force
>> specific jar version to be loaded in solrconfig?
>> 2. More in general: is it possible to expose in solr the version number for
>> custom plugins?
>> Thank you in advance
>> 
> 


-
King Rhoton, c/o Adobe, 601 Townsend, SF, CA 94103
415-832-4480 x24480
S support requests should go to search-...@adobe.com

Re: custom plugin version

[Andrea Gazzarini]

Hi Zaccheo,
I don't think this is possible, this is something related with the 
classloader behavior, and even if there's a "priority" rule in the JVM, 
I wouldn't rely on that in my application.
That could be good in a dev environment where you can specify the 
"order" of the imported libraries (e.g. Eclipse), but definitely not so 
good outside (IMO).


As far as I know, there's no a built-in way to declare the version of 
custom components, but you could adopt the same approach of Lucene, with 
something like a Version class that drives the behavior of your component.

In this way you will have

 * always one jar (better: unique classes FQNs), so no classloader issues
 * a behavior that changes depending on the configuration

Best,
Andrea

On 03/02/17 10:57, Zaccheo Bagnati wrote:

Hi all,
I developed a custom DocTransformer that is loaded from a .jar in the core
"lib" directory. It works but I have now a problem with versioning:
1. if lib directory contains different versions of the same .jar which one
is loaded? I tried putting both myplugins-1.0.0.jar and myplugins-1.0.1.jar
and I noticed that the oldest one is loaded. Is there a way to force
specific jar version to be loaded in solrconfig?
2. More in general: is it possible to expose in solr the version number for
custom plugins?
Thank you in advance

custom plugin version

[Zaccheo Bagnati]

Hi all,
I developed a custom DocTransformer that is loaded from a .jar in the core
"lib" directory. It works but I have now a problem with versioning:
1. if lib directory contains different versions of the same .jar which one
is loaded? I tried putting both myplugins-1.0.0.jar and myplugins-1.0.1.jar
and I noticed that the oldest one is loaded. Is there a way to force
specific jar version to be loaded in solrconfig?
2. More in general: is it possible to expose in solr the version number for
custom plugins?
Thank you in advance