Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BREAKING: Lucene.Net.QueryParsers.Flexible: Removed NLS Support #484

Merged
merged 4 commits into from
May 4, 2021

Conversation

NightOwl888
Copy link
Contributor

This removes support for NLS. This feature allowed lazy-loading of localized resource messages, but required the exceptions to accept an IMessage instance instead of a string. This makes it very inconvenient to use the following exception types in the Lucene.Net.QueryParsers.Flexible namespace:

  • Core.QueryNodeError
  • Core.QueryNodeException
  • Core.QueryNodeParseException
  • Standard.Parser.ParseException

These exceptions were refactored to accept a string message and to accept an innerException so they can be properly re-thrown. It also allows users to supply their own exception messages inline more easily with the option to use resource files, if desired.

This also removes Lucene.Net.Util.BundleResourceManagerFactory and IResourceManagerFactory which were to allow users to supply their own ResourceManger instance based on the type passed. BundleResourceManagerFactory and NLS were awkward to use because they required a "Bundle" suffix on the resource that was added to the project and to add a subclass of NLS with static fields even though Visual Studio already generates one.

The following classes were removed from the Lucene.Net.QueryParsers.Flexible namespace:

  • Messages.Message
  • Messages.IMessage
  • Messages.NLS
  • Messages.INLSException

The Java-like design was abandoned and QueryParserMessages was redesigned to be similar to the auto-generated class for QueryParser, however it now uses a class named QueryParserResourceProvider (which implements IResourceProvider) that contains the fallback logic for supplying custom ResourceProvider instances without any special constraints on the naming or other conventions used for creating the resources. End users can supply their own resources by setting the IResourceProvider at application startup. The built-in implementation, QueryParserResourceProvider accepts zero to many ResourceManager instances in its constructor, so supplying localized messages is now as easy as:

QueryParserMessages.SetResourceProvider(
    new QueryParserResourceProvider(SomeResource.ResourceManager, SomeOtherResource.ResourceManager));

at application startup.

The old NLS tests were commented out, and tests were added for the new features to confirm the fallback logic is working correctly.

…upport and changed exceptions to use string messages so end users can elect whether to use .NET localization or not
…amespace, as we have refactored to use .NET localization rather than NLS
…ResourceManagerFactory, as these were only to support NLS
…rMessages.cs so that it is just a facade around a IResourceProvider implementation that provides the actual fallback logic. Added a QueryParserResourceProvider implementation that can be passed zero to many ResourceProvider instances to override and optionally localize the default resource messages.
@NightOwl888 NightOwl888 merged commit c15328f into apache:master May 4, 2021
@NightOwl888 NightOwl888 added this to the 4.8.0-beta00015 milestone Oct 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant