lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shad Storhaug (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (LUCENENET-572) Make Lucene.Net.Expressions Configurable via Dependency Injection
Date Thu, 13 Apr 2017 00:42:41 GMT

     [ 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)

Mime
View raw message