You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Steven Bower <sm...@alcyon.net> on 2014/01/14 19:41:23 UTC
core.properties and solr.xml
Are there any plans/tickets to allow for pluggable SolrConf and
CoreLocator? In my use case my solr.xml is totally static, i have a
separate dataDir and my core.properties are derived from a separate
configuration (living in ZK) but totally outside of the SolrCloud..
I'd like to be able to not have any instance directories and/or no solr.xml
or core.properties files laying around as right now I just regenerate them
on startup each time in my start scripts..
Obviously I can just hack my stuff in and clearly this could break the
write side of the collections API (which i don't care about for my case)...
but having a way to plug these would be nice..
steve
Re: core.properties and solr.xml
Posted by Steven Bower <sb...@alcyon.net>.
For us we don't fully rely on cloud/collections api for creating and
deploying instances/etc.. we control this via an external mechanism so this
would allow me to have instances figure out what they should be based on an
external system.. we do this now but have to drop core.properties files all
over.. i'd like to not have to do that... its more of a desire for
cleanliness of my filesystem than anything else because this is all
automated at this point..
On Wed, Jan 15, 2014 at 1:49 PM, Mark Miller <ma...@gmail.com> wrote:
> What’s the benefit? So you can avoid having a simple core properties file?
> I’d rather see more value than that prompt exposing something like this to
> the user. It’s a can of warms that I personally have not seen a lot of
> value in yet.
>
> Whether we mark it experimental or not, this adds a burden, and I’m still
> wondering if the gains are worth it.
>
> - Mark
>
> On Jan 15, 2014, at 12:04 PM, Alan Woodward <al...@flax.co.uk> wrote:
>
> > This is true. But if we slap big "warning: experimental" messages all
> over it, then users can't complain too much about backwards-compat breaks.
> My intention when pulling all this stuff into the CoresLocator interface
> was to allow other implementations to be tested out, and other suggestions
> have already come up from time to time on the list. It seems a shame to
> *not* allow this to be opened up for advanced users.
> >
> > Alan Woodward
> > www.flax.co.uk
> >
> >
> > On 15 Jan 2014, at 16:24, Mark Miller wrote:
> >
> >> I think these API’s are pretty new and deep to want to support them for
> users at this point. It constrains refactoring and can complicates things
> down the line, especially with SolrCloud. This same discussion has come up
> in JIRA issues before. At best, I think all the recent refactoring in this
> area needs to bake.
> >>
> >> - Mark
> >>
> >> On Jan 15, 2014, at 11:01 AM, Alan Woodward <al...@flax.co.uk> wrote:
> >>
> >>> I think solr.xml is the correct place for it, and you can then set up
> substitution variables to allow it to be set by environment variables, etc.
> But let's discuss on the JIRA ticket.
> >>>
> >>> Alan Woodward
> >>> www.flax.co.uk
> >>>
> >>>
> >>> On 15 Jan 2014, at 15:39, Steven Bower wrote:
> >>>
> >>>> I will open up a JIRA... I'm more concerned over the core locator
> stuff vs
> >>>> the solr.xml.. Should the specification of the core locator go into
> the
> >>>> solr.xml or via some other method?
> >>>>
> >>>> steve
> >>>>
> >>>>
> >>>> On Tue, Jan 14, 2014 at 5:06 PM, Alan Woodward <al...@flax.co.uk>
> wrote:
> >>>>
> >>>>> Hi Steve,
> >>>>>
> >>>>> I think this is a great idea. Currently the implementation of
> >>>>> CoresLocator is picked depending on the type of solr.xml you have
> (new- vs
> >>>>> old-style), but it should be easy enough to extend the new-style
> logic to
> >>>>> optionally look up and instantiate a plugin implementation.
> >>>>>
> >>>>> Core loading and new core creation is all done through the CL now,
> so as
> >>>>> long as the plugin implemented all methods, it shouldn't break the
> >>>>> Collections API either.
> >>>>>
> >>>>> Do you want to open a JIRA?
> >>>>>
> >>>>> Alan Woodward
> >>>>> www.flax.co.uk
> >>>>>
> >>>>>
> >>>>> On 14 Jan 2014, at 19:20, Erick Erickson wrote:
> >>>>>
> >>>>>> The work done as part of "new style" solr.xml, particularly by
> >>>>>> romsegeek should make this a lot easier. But no, there's no formal
> >>>>>> support for such a thing.
> >>>>>>
> >>>>>> There's also a desire to make ZK "the one source of truth" in Solr
> 5,
> >>>>>> although that effort is in early stages.
> >>>>>>
> >>>>>> Which is a long way of saying that I think this would be a good
> thing
> >>>>>> to add. Currently there's no formal way to specify one though. We'd
> >>>>>> have to give some thought as to what abstract methods are required.
> >>>>>> The current "old style" and "new style" classes . There's also the
> >>>>>> chicken-and-egg question; how does one specify the new class? This
> >>>>>> seems like something that would be in a (very small) solr.xml or
> >>>>>> specified as a sysprop. And knowing where to load the class from
> could
> >>>>>> be "interesting".
> >>>>>>
> >>>>>> A pluggable SolrConfig I think is a stickier wicket, it hasn't been
> >>>>>> broken out into nice interfaces like coreslocator has been. And it's
> >>>>>> used all over the place, passed in and recorded in constructors etc,
> >>>>>> as well as being possibly unique for each core. There's been some
> talk
> >>>>>> of sharing a single config object, and there's also talk about using
> >>>>>> "config sets" that might address some of those concerns, but neither
> >>>>>> one has gotten very far in 4x land.
> >>>>>>
> >>>>>> FWIW,
> >>>>>> Erick
> >>>>>>
> >>>>>> On Tue, Jan 14, 2014 at 1:41 PM, Steven Bower <
> smb-apache@alcyon.net>
> >>>>> wrote:
> >>>>>>> Are there any plans/tickets to allow for pluggable SolrConf and
> >>>>>>> CoreLocator? In my use case my solr.xml is totally static, i have a
> >>>>>>> separate dataDir and my core.properties are derived from a separate
> >>>>>>> configuration (living in ZK) but totally outside of the SolrCloud..
> >>>>>>>
> >>>>>>> I'd like to be able to not have any instance directories and/or no
> >>>>> solr.xml
> >>>>>>> or core.properties files laying around as right now I just
> regenerate
> >>>>> them
> >>>>>>> on startup each time in my start scripts..
> >>>>>>>
> >>>>>>> Obviously I can just hack my stuff in and clearly this could break
> the
> >>>>>>> write side of the collections API (which i don't care about for my
> >>>>> case)...
> >>>>>>> but having a way to plug these would be nice..
> >>>>>>>
> >>>>>>> steve
> >>>>>
> >>>>>
> >>>
> >>
> >
>
>
Re: core.properties and solr.xml
Posted by Mark Miller <ma...@gmail.com>.
What’s the benefit? So you can avoid having a simple core properties file? I’d rather see more value than that prompt exposing something like this to the user. It’s a can of warms that I personally have not seen a lot of value in yet.
Whether we mark it experimental or not, this adds a burden, and I’m still wondering if the gains are worth it.
- Mark
On Jan 15, 2014, at 12:04 PM, Alan Woodward <al...@flax.co.uk> wrote:
> This is true. But if we slap big "warning: experimental" messages all over it, then users can't complain too much about backwards-compat breaks. My intention when pulling all this stuff into the CoresLocator interface was to allow other implementations to be tested out, and other suggestions have already come up from time to time on the list. It seems a shame to *not* allow this to be opened up for advanced users.
>
> Alan Woodward
> www.flax.co.uk
>
>
> On 15 Jan 2014, at 16:24, Mark Miller wrote:
>
>> I think these API’s are pretty new and deep to want to support them for users at this point. It constrains refactoring and can complicates things down the line, especially with SolrCloud. This same discussion has come up in JIRA issues before. At best, I think all the recent refactoring in this area needs to bake.
>>
>> - Mark
>>
>> On Jan 15, 2014, at 11:01 AM, Alan Woodward <al...@flax.co.uk> wrote:
>>
>>> I think solr.xml is the correct place for it, and you can then set up substitution variables to allow it to be set by environment variables, etc. But let's discuss on the JIRA ticket.
>>>
>>> Alan Woodward
>>> www.flax.co.uk
>>>
>>>
>>> On 15 Jan 2014, at 15:39, Steven Bower wrote:
>>>
>>>> I will open up a JIRA... I'm more concerned over the core locator stuff vs
>>>> the solr.xml.. Should the specification of the core locator go into the
>>>> solr.xml or via some other method?
>>>>
>>>> steve
>>>>
>>>>
>>>> On Tue, Jan 14, 2014 at 5:06 PM, Alan Woodward <al...@flax.co.uk> wrote:
>>>>
>>>>> Hi Steve,
>>>>>
>>>>> I think this is a great idea. Currently the implementation of
>>>>> CoresLocator is picked depending on the type of solr.xml you have (new- vs
>>>>> old-style), but it should be easy enough to extend the new-style logic to
>>>>> optionally look up and instantiate a plugin implementation.
>>>>>
>>>>> Core loading and new core creation is all done through the CL now, so as
>>>>> long as the plugin implemented all methods, it shouldn't break the
>>>>> Collections API either.
>>>>>
>>>>> Do you want to open a JIRA?
>>>>>
>>>>> Alan Woodward
>>>>> www.flax.co.uk
>>>>>
>>>>>
>>>>> On 14 Jan 2014, at 19:20, Erick Erickson wrote:
>>>>>
>>>>>> The work done as part of "new style" solr.xml, particularly by
>>>>>> romsegeek should make this a lot easier. But no, there's no formal
>>>>>> support for such a thing.
>>>>>>
>>>>>> There's also a desire to make ZK "the one source of truth" in Solr 5,
>>>>>> although that effort is in early stages.
>>>>>>
>>>>>> Which is a long way of saying that I think this would be a good thing
>>>>>> to add. Currently there's no formal way to specify one though. We'd
>>>>>> have to give some thought as to what abstract methods are required.
>>>>>> The current "old style" and "new style" classes . There's also the
>>>>>> chicken-and-egg question; how does one specify the new class? This
>>>>>> seems like something that would be in a (very small) solr.xml or
>>>>>> specified as a sysprop. And knowing where to load the class from could
>>>>>> be "interesting".
>>>>>>
>>>>>> A pluggable SolrConfig I think is a stickier wicket, it hasn't been
>>>>>> broken out into nice interfaces like coreslocator has been. And it's
>>>>>> used all over the place, passed in and recorded in constructors etc,
>>>>>> as well as being possibly unique for each core. There's been some talk
>>>>>> of sharing a single config object, and there's also talk about using
>>>>>> "config sets" that might address some of those concerns, but neither
>>>>>> one has gotten very far in 4x land.
>>>>>>
>>>>>> FWIW,
>>>>>> Erick
>>>>>>
>>>>>> On Tue, Jan 14, 2014 at 1:41 PM, Steven Bower <sm...@alcyon.net>
>>>>> wrote:
>>>>>>> Are there any plans/tickets to allow for pluggable SolrConf and
>>>>>>> CoreLocator? In my use case my solr.xml is totally static, i have a
>>>>>>> separate dataDir and my core.properties are derived from a separate
>>>>>>> configuration (living in ZK) but totally outside of the SolrCloud..
>>>>>>>
>>>>>>> I'd like to be able to not have any instance directories and/or no
>>>>> solr.xml
>>>>>>> or core.properties files laying around as right now I just regenerate
>>>>> them
>>>>>>> on startup each time in my start scripts..
>>>>>>>
>>>>>>> Obviously I can just hack my stuff in and clearly this could break the
>>>>>>> write side of the collections API (which i don't care about for my
>>>>> case)...
>>>>>>> but having a way to plug these would be nice..
>>>>>>>
>>>>>>> steve
>>>>>
>>>>>
>>>
>>
>
Re: core.properties and solr.xml
Posted by Alan Woodward <al...@flax.co.uk>.
This is true. But if we slap big "warning: experimental" messages all over it, then users can't complain too much about backwards-compat breaks. My intention when pulling all this stuff into the CoresLocator interface was to allow other implementations to be tested out, and other suggestions have already come up from time to time on the list. It seems a shame to *not* allow this to be opened up for advanced users.
Alan Woodward
www.flax.co.uk
On 15 Jan 2014, at 16:24, Mark Miller wrote:
> I think these API’s are pretty new and deep to want to support them for users at this point. It constrains refactoring and can complicates things down the line, especially with SolrCloud. This same discussion has come up in JIRA issues before. At best, I think all the recent refactoring in this area needs to bake.
>
> - Mark
>
> On Jan 15, 2014, at 11:01 AM, Alan Woodward <al...@flax.co.uk> wrote:
>
>> I think solr.xml is the correct place for it, and you can then set up substitution variables to allow it to be set by environment variables, etc. But let's discuss on the JIRA ticket.
>>
>> Alan Woodward
>> www.flax.co.uk
>>
>>
>> On 15 Jan 2014, at 15:39, Steven Bower wrote:
>>
>>> I will open up a JIRA... I'm more concerned over the core locator stuff vs
>>> the solr.xml.. Should the specification of the core locator go into the
>>> solr.xml or via some other method?
>>>
>>> steve
>>>
>>>
>>> On Tue, Jan 14, 2014 at 5:06 PM, Alan Woodward <al...@flax.co.uk> wrote:
>>>
>>>> Hi Steve,
>>>>
>>>> I think this is a great idea. Currently the implementation of
>>>> CoresLocator is picked depending on the type of solr.xml you have (new- vs
>>>> old-style), but it should be easy enough to extend the new-style logic to
>>>> optionally look up and instantiate a plugin implementation.
>>>>
>>>> Core loading and new core creation is all done through the CL now, so as
>>>> long as the plugin implemented all methods, it shouldn't break the
>>>> Collections API either.
>>>>
>>>> Do you want to open a JIRA?
>>>>
>>>> Alan Woodward
>>>> www.flax.co.uk
>>>>
>>>>
>>>> On 14 Jan 2014, at 19:20, Erick Erickson wrote:
>>>>
>>>>> The work done as part of "new style" solr.xml, particularly by
>>>>> romsegeek should make this a lot easier. But no, there's no formal
>>>>> support for such a thing.
>>>>>
>>>>> There's also a desire to make ZK "the one source of truth" in Solr 5,
>>>>> although that effort is in early stages.
>>>>>
>>>>> Which is a long way of saying that I think this would be a good thing
>>>>> to add. Currently there's no formal way to specify one though. We'd
>>>>> have to give some thought as to what abstract methods are required.
>>>>> The current "old style" and "new style" classes . There's also the
>>>>> chicken-and-egg question; how does one specify the new class? This
>>>>> seems like something that would be in a (very small) solr.xml or
>>>>> specified as a sysprop. And knowing where to load the class from could
>>>>> be "interesting".
>>>>>
>>>>> A pluggable SolrConfig I think is a stickier wicket, it hasn't been
>>>>> broken out into nice interfaces like coreslocator has been. And it's
>>>>> used all over the place, passed in and recorded in constructors etc,
>>>>> as well as being possibly unique for each core. There's been some talk
>>>>> of sharing a single config object, and there's also talk about using
>>>>> "config sets" that might address some of those concerns, but neither
>>>>> one has gotten very far in 4x land.
>>>>>
>>>>> FWIW,
>>>>> Erick
>>>>>
>>>>> On Tue, Jan 14, 2014 at 1:41 PM, Steven Bower <sm...@alcyon.net>
>>>> wrote:
>>>>>> Are there any plans/tickets to allow for pluggable SolrConf and
>>>>>> CoreLocator? In my use case my solr.xml is totally static, i have a
>>>>>> separate dataDir and my core.properties are derived from a separate
>>>>>> configuration (living in ZK) but totally outside of the SolrCloud..
>>>>>>
>>>>>> I'd like to be able to not have any instance directories and/or no
>>>> solr.xml
>>>>>> or core.properties files laying around as right now I just regenerate
>>>> them
>>>>>> on startup each time in my start scripts..
>>>>>>
>>>>>> Obviously I can just hack my stuff in and clearly this could break the
>>>>>> write side of the collections API (which i don't care about for my
>>>> case)...
>>>>>> but having a way to plug these would be nice..
>>>>>>
>>>>>> steve
>>>>
>>>>
>>
>
Re: core.properties and solr.xml
Posted by Mark Miller <ma...@gmail.com>.
I think these API’s are pretty new and deep to want to support them for users at this point. It constrains refactoring and can complicates things down the line, especially with SolrCloud. This same discussion has come up in JIRA issues before. At best, I think all the recent refactoring in this area needs to bake.
- Mark
On Jan 15, 2014, at 11:01 AM, Alan Woodward <al...@flax.co.uk> wrote:
> I think solr.xml is the correct place for it, and you can then set up substitution variables to allow it to be set by environment variables, etc. But let's discuss on the JIRA ticket.
>
> Alan Woodward
> www.flax.co.uk
>
>
> On 15 Jan 2014, at 15:39, Steven Bower wrote:
>
>> I will open up a JIRA... I'm more concerned over the core locator stuff vs
>> the solr.xml.. Should the specification of the core locator go into the
>> solr.xml or via some other method?
>>
>> steve
>>
>>
>> On Tue, Jan 14, 2014 at 5:06 PM, Alan Woodward <al...@flax.co.uk> wrote:
>>
>>> Hi Steve,
>>>
>>> I think this is a great idea. Currently the implementation of
>>> CoresLocator is picked depending on the type of solr.xml you have (new- vs
>>> old-style), but it should be easy enough to extend the new-style logic to
>>> optionally look up and instantiate a plugin implementation.
>>>
>>> Core loading and new core creation is all done through the CL now, so as
>>> long as the plugin implemented all methods, it shouldn't break the
>>> Collections API either.
>>>
>>> Do you want to open a JIRA?
>>>
>>> Alan Woodward
>>> www.flax.co.uk
>>>
>>>
>>> On 14 Jan 2014, at 19:20, Erick Erickson wrote:
>>>
>>>> The work done as part of "new style" solr.xml, particularly by
>>>> romsegeek should make this a lot easier. But no, there's no formal
>>>> support for such a thing.
>>>>
>>>> There's also a desire to make ZK "the one source of truth" in Solr 5,
>>>> although that effort is in early stages.
>>>>
>>>> Which is a long way of saying that I think this would be a good thing
>>>> to add. Currently there's no formal way to specify one though. We'd
>>>> have to give some thought as to what abstract methods are required.
>>>> The current "old style" and "new style" classes . There's also the
>>>> chicken-and-egg question; how does one specify the new class? This
>>>> seems like something that would be in a (very small) solr.xml or
>>>> specified as a sysprop. And knowing where to load the class from could
>>>> be "interesting".
>>>>
>>>> A pluggable SolrConfig I think is a stickier wicket, it hasn't been
>>>> broken out into nice interfaces like coreslocator has been. And it's
>>>> used all over the place, passed in and recorded in constructors etc,
>>>> as well as being possibly unique for each core. There's been some talk
>>>> of sharing a single config object, and there's also talk about using
>>>> "config sets" that might address some of those concerns, but neither
>>>> one has gotten very far in 4x land.
>>>>
>>>> FWIW,
>>>> Erick
>>>>
>>>> On Tue, Jan 14, 2014 at 1:41 PM, Steven Bower <sm...@alcyon.net>
>>> wrote:
>>>>> Are there any plans/tickets to allow for pluggable SolrConf and
>>>>> CoreLocator? In my use case my solr.xml is totally static, i have a
>>>>> separate dataDir and my core.properties are derived from a separate
>>>>> configuration (living in ZK) but totally outside of the SolrCloud..
>>>>>
>>>>> I'd like to be able to not have any instance directories and/or no
>>> solr.xml
>>>>> or core.properties files laying around as right now I just regenerate
>>> them
>>>>> on startup each time in my start scripts..
>>>>>
>>>>> Obviously I can just hack my stuff in and clearly this could break the
>>>>> write side of the collections API (which i don't care about for my
>>> case)...
>>>>> but having a way to plug these would be nice..
>>>>>
>>>>> steve
>>>
>>>
>
Re: core.properties and solr.xml
Posted by Alan Woodward <al...@flax.co.uk>.
I think solr.xml is the correct place for it, and you can then set up substitution variables to allow it to be set by environment variables, etc. But let's discuss on the JIRA ticket.
Alan Woodward
www.flax.co.uk
On 15 Jan 2014, at 15:39, Steven Bower wrote:
> I will open up a JIRA... I'm more concerned over the core locator stuff vs
> the solr.xml.. Should the specification of the core locator go into the
> solr.xml or via some other method?
>
> steve
>
>
> On Tue, Jan 14, 2014 at 5:06 PM, Alan Woodward <al...@flax.co.uk> wrote:
>
>> Hi Steve,
>>
>> I think this is a great idea. Currently the implementation of
>> CoresLocator is picked depending on the type of solr.xml you have (new- vs
>> old-style), but it should be easy enough to extend the new-style logic to
>> optionally look up and instantiate a plugin implementation.
>>
>> Core loading and new core creation is all done through the CL now, so as
>> long as the plugin implemented all methods, it shouldn't break the
>> Collections API either.
>>
>> Do you want to open a JIRA?
>>
>> Alan Woodward
>> www.flax.co.uk
>>
>>
>> On 14 Jan 2014, at 19:20, Erick Erickson wrote:
>>
>>> The work done as part of "new style" solr.xml, particularly by
>>> romsegeek should make this a lot easier. But no, there's no formal
>>> support for such a thing.
>>>
>>> There's also a desire to make ZK "the one source of truth" in Solr 5,
>>> although that effort is in early stages.
>>>
>>> Which is a long way of saying that I think this would be a good thing
>>> to add. Currently there's no formal way to specify one though. We'd
>>> have to give some thought as to what abstract methods are required.
>>> The current "old style" and "new style" classes . There's also the
>>> chicken-and-egg question; how does one specify the new class? This
>>> seems like something that would be in a (very small) solr.xml or
>>> specified as a sysprop. And knowing where to load the class from could
>>> be "interesting".
>>>
>>> A pluggable SolrConfig I think is a stickier wicket, it hasn't been
>>> broken out into nice interfaces like coreslocator has been. And it's
>>> used all over the place, passed in and recorded in constructors etc,
>>> as well as being possibly unique for each core. There's been some talk
>>> of sharing a single config object, and there's also talk about using
>>> "config sets" that might address some of those concerns, but neither
>>> one has gotten very far in 4x land.
>>>
>>> FWIW,
>>> Erick
>>>
>>> On Tue, Jan 14, 2014 at 1:41 PM, Steven Bower <sm...@alcyon.net>
>> wrote:
>>>> Are there any plans/tickets to allow for pluggable SolrConf and
>>>> CoreLocator? In my use case my solr.xml is totally static, i have a
>>>> separate dataDir and my core.properties are derived from a separate
>>>> configuration (living in ZK) but totally outside of the SolrCloud..
>>>>
>>>> I'd like to be able to not have any instance directories and/or no
>> solr.xml
>>>> or core.properties files laying around as right now I just regenerate
>> them
>>>> on startup each time in my start scripts..
>>>>
>>>> Obviously I can just hack my stuff in and clearly this could break the
>>>> write side of the collections API (which i don't care about for my
>> case)...
>>>> but having a way to plug these would be nice..
>>>>
>>>> steve
>>
>>
Re: core.properties and solr.xml
Posted by Steven Bower <sm...@alcyon.net>.
I will open up a JIRA... I'm more concerned over the core locator stuff vs
the solr.xml.. Should the specification of the core locator go into the
solr.xml or via some other method?
steve
On Tue, Jan 14, 2014 at 5:06 PM, Alan Woodward <al...@flax.co.uk> wrote:
> Hi Steve,
>
> I think this is a great idea. Currently the implementation of
> CoresLocator is picked depending on the type of solr.xml you have (new- vs
> old-style), but it should be easy enough to extend the new-style logic to
> optionally look up and instantiate a plugin implementation.
>
> Core loading and new core creation is all done through the CL now, so as
> long as the plugin implemented all methods, it shouldn't break the
> Collections API either.
>
> Do you want to open a JIRA?
>
> Alan Woodward
> www.flax.co.uk
>
>
> On 14 Jan 2014, at 19:20, Erick Erickson wrote:
>
> > The work done as part of "new style" solr.xml, particularly by
> > romsegeek should make this a lot easier. But no, there's no formal
> > support for such a thing.
> >
> > There's also a desire to make ZK "the one source of truth" in Solr 5,
> > although that effort is in early stages.
> >
> > Which is a long way of saying that I think this would be a good thing
> > to add. Currently there's no formal way to specify one though. We'd
> > have to give some thought as to what abstract methods are required.
> > The current "old style" and "new style" classes . There's also the
> > chicken-and-egg question; how does one specify the new class? This
> > seems like something that would be in a (very small) solr.xml or
> > specified as a sysprop. And knowing where to load the class from could
> > be "interesting".
> >
> > A pluggable SolrConfig I think is a stickier wicket, it hasn't been
> > broken out into nice interfaces like coreslocator has been. And it's
> > used all over the place, passed in and recorded in constructors etc,
> > as well as being possibly unique for each core. There's been some talk
> > of sharing a single config object, and there's also talk about using
> > "config sets" that might address some of those concerns, but neither
> > one has gotten very far in 4x land.
> >
> > FWIW,
> > Erick
> >
> > On Tue, Jan 14, 2014 at 1:41 PM, Steven Bower <sm...@alcyon.net>
> wrote:
> >> Are there any plans/tickets to allow for pluggable SolrConf and
> >> CoreLocator? In my use case my solr.xml is totally static, i have a
> >> separate dataDir and my core.properties are derived from a separate
> >> configuration (living in ZK) but totally outside of the SolrCloud..
> >>
> >> I'd like to be able to not have any instance directories and/or no
> solr.xml
> >> or core.properties files laying around as right now I just regenerate
> them
> >> on startup each time in my start scripts..
> >>
> >> Obviously I can just hack my stuff in and clearly this could break the
> >> write side of the collections API (which i don't care about for my
> case)...
> >> but having a way to plug these would be nice..
> >>
> >> steve
>
>
Re: core.properties and solr.xml
Posted by Alan Woodward <al...@flax.co.uk>.
Hi Steve,
I think this is a great idea. Currently the implementation of CoresLocator is picked depending on the type of solr.xml you have (new- vs old-style), but it should be easy enough to extend the new-style logic to optionally look up and instantiate a plugin implementation.
Core loading and new core creation is all done through the CL now, so as long as the plugin implemented all methods, it shouldn't break the Collections API either.
Do you want to open a JIRA?
Alan Woodward
www.flax.co.uk
On 14 Jan 2014, at 19:20, Erick Erickson wrote:
> The work done as part of "new style" solr.xml, particularly by
> romsegeek should make this a lot easier. But no, there's no formal
> support for such a thing.
>
> There's also a desire to make ZK "the one source of truth" in Solr 5,
> although that effort is in early stages.
>
> Which is a long way of saying that I think this would be a good thing
> to add. Currently there's no formal way to specify one though. We'd
> have to give some thought as to what abstract methods are required.
> The current "old style" and "new style" classes . There's also the
> chicken-and-egg question; how does one specify the new class? This
> seems like something that would be in a (very small) solr.xml or
> specified as a sysprop. And knowing where to load the class from could
> be "interesting".
>
> A pluggable SolrConfig I think is a stickier wicket, it hasn't been
> broken out into nice interfaces like coreslocator has been. And it's
> used all over the place, passed in and recorded in constructors etc,
> as well as being possibly unique for each core. There's been some talk
> of sharing a single config object, and there's also talk about using
> "config sets" that might address some of those concerns, but neither
> one has gotten very far in 4x land.
>
> FWIW,
> Erick
>
> On Tue, Jan 14, 2014 at 1:41 PM, Steven Bower <sm...@alcyon.net> wrote:
>> Are there any plans/tickets to allow for pluggable SolrConf and
>> CoreLocator? In my use case my solr.xml is totally static, i have a
>> separate dataDir and my core.properties are derived from a separate
>> configuration (living in ZK) but totally outside of the SolrCloud..
>>
>> I'd like to be able to not have any instance directories and/or no solr.xml
>> or core.properties files laying around as right now I just regenerate them
>> on startup each time in my start scripts..
>>
>> Obviously I can just hack my stuff in and clearly this could break the
>> write side of the collections API (which i don't care about for my case)...
>> but having a way to plug these would be nice..
>>
>> steve
Re: core.properties and solr.xml
Posted by Erick Erickson <er...@gmail.com>.
The work done as part of "new style" solr.xml, particularly by
romsegeek should make this a lot easier. But no, there's no formal
support for such a thing.
There's also a desire to make ZK "the one source of truth" in Solr 5,
although that effort is in early stages.
Which is a long way of saying that I think this would be a good thing
to add. Currently there's no formal way to specify one though. We'd
have to give some thought as to what abstract methods are required.
The current "old style" and "new style" classes . There's also the
chicken-and-egg question; how does one specify the new class? This
seems like something that would be in a (very small) solr.xml or
specified as a sysprop. And knowing where to load the class from could
be "interesting".
A pluggable SolrConfig I think is a stickier wicket, it hasn't been
broken out into nice interfaces like coreslocator has been. And it's
used all over the place, passed in and recorded in constructors etc,
as well as being possibly unique for each core. There's been some talk
of sharing a single config object, and there's also talk about using
"config sets" that might address some of those concerns, but neither
one has gotten very far in 4x land.
FWIW,
Erick
On Tue, Jan 14, 2014 at 1:41 PM, Steven Bower <sm...@alcyon.net> wrote:
> Are there any plans/tickets to allow for pluggable SolrConf and
> CoreLocator? In my use case my solr.xml is totally static, i have a
> separate dataDir and my core.properties are derived from a separate
> configuration (living in ZK) but totally outside of the SolrCloud..
>
> I'd like to be able to not have any instance directories and/or no solr.xml
> or core.properties files laying around as right now I just regenerate them
> on startup each time in my start scripts..
>
> Obviously I can just hack my stuff in and clearly this could break the
> write side of the collections API (which i don't care about for my case)...
> but having a way to plug these would be nice..
>
> steve