[ 
https://issues.apache.org/jira/browse/LUCENENET-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shad Storhaug resolved LUCENENET-572.
-------------------------------------
       Resolution: Fixed
    Fix Version/s: Lucene.Net 5.0 PCL

This turned out to be user property settings that are not supported in .NET 
Core. The extra configuration classes only loaded the settings from the legacy 
.settings file into a dictionary that the rest of the library used as the 
default settings. Since it is possible to make custom functions without using 
this configuration, this extra setting was removed from the .NET Core version. 
The extra configuration classes and dependencies have also been removed.

> Make Lucene.Net.Expressions Configurable via Dependency Injection
> -----------------------------------------------------------------
>
>                 Key: LUCENENET-572
>                 URL: https://issues.apache.org/jira/browse/LUCENENET-572
>             Project: Lucene.Net
>          Issue Type: Improvement
>    Affects Versions: Lucene.Net 5.0 PCL
>            Reporter: Shad Storhaug
>             Fix For: Lucene.Net 5.0 PCL
>
>
> Lucene.Net.Expressions currently reads its function data from a configuration 
> file using Support.Configuration classes. We should aim to "push" the 
> configuration down from the consuming application rather than "pull" it from 
> a source that the consuming application does not control.
> In Java, the initial list of functions was in an embedded text file, and it 
> could be extended by passing in a ClassLoader (which is roughly equivalent to 
> .NET's Assembly class). For some reason, the .NET implementation has some 
> auto-generated wrapper code, and it is unclear what auto-generated it and if 
> it can be re-generated. We need to investigate why the implementation is so 
> different, and make it Dependency Injection friendly.
> After this task is complete the Support.Configuration namespace should be 
> deleted. All configuration should be supplied directly by the consuming 
> application, not pulled from configuration files.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to