croz-ltd / nrich Goto Github PK

Basic information

• nrich version:
  1.2.1
• Module:
  Project

Additional information

Enhancement description

It would be good for users to be able to change path in all the controllers with the ones specified in property values.

Current behaviour

Wanted behaviour

All controller have fully customisable URI.

Possible workarounds

Basic information

• nrich version:
  1.2.1
• Module:
  project

Additional information

Enhancement description

At the moment, all Javadoc can be found in the repository, by browsing the code.

From user perspective, it would be easier to read Javadoc through a web page UI. One possible solution is GitHub Pages.

Current behaviour

No web page/UI for nrich Javadoc present.

Wanted behaviour

Web page/UI for nrich Javadoc present.

Possible workarounds

Basic information

• nrich version:
  1.2.1
• Module:
  nrich-search, nrich-registry

Additional information

Enhancement description

Current date formats are not inline with each other, value for date is using dots and value for datetime is using dashes as separator ("dd.MM.yyyy", "yyyy-MM-dd'T'HH:mm" ) sync them to use the same format by adding one additional for date and datetime.

Current behaviour

Date and datetime format differ in separator used.

Wanted behaviour

Date and datetime format use the same separator.

Possible workarounds

Basic information

• nrich version:
  1.2.1
• Module:
  Project
• Link to the complete executable reproducer if available (e.g. GitHub Repo):

Additional information

Bug description

Not all beans in autoconfiguration classes have @ConditionalOnMissingBean annotation, go through the code and add where it is missing.

Steps to reproduce

Expected behavior

Actual behavior

Basic information

• nrich version:
  1.2.1
• Module:
  nrich-encrypt
• Link to the complete executable reproducer if available (e.g. GitHub Repo):

Additional information

Bug description

If using webflux with nrich-encrypt current principal is not resolved correctly. In the DefaultDataEncryptService implementation of DataEncryptionService the current principal is not used at all so it won't cause any issues. If the users decide to implement their own service and rely on the resolved principal in EncryptionContext there will be issues. The principal is resolved using SecurityContextHolder.getContext() which has its alternative in webflux in ReactiveSecurityContextHolder.

Steps to reproduce

Expected behavior

The principal is resolved correctly in webmvc and webflux environments.

Actual behavior

The principal is not resolved in webflux environment.

Basic information

• nrich version:
  1.2.1
• Module:
  nrich-webmvc
• Link to the complete executable reproducer if available (e.g. GitHub Repo):

Additional information

Bug description

NotificationErrorHandlingRestControllerAdvice supports unwrapping of exceptions and response resolving uses unwrapped exception, but the status is not resolved using the unwrapped but the original exception.

Steps to reproduce

Configure a status for an exception in message.properties and throw an exception that should be unwrapped i.e ExecutionException, the configured status won't be returned.

Expected behavior

The status configured for unwrapped exception is returned.

Actual behavior

The status configured for original exception is returned.

Basic information

• nrich version:
  1.4.0
• Module:
  nrich-search

Bug description

The SearchExecutorJpaRepositoryFactoryBean initialization fails when beanFactory.getBean() methods are called during beanFactory initialization (i.e., from Spring Boot auto-configurations executed after nrich-search-spring-boot-starter auto-configuration).

The SearchExecutorJpaRepositoryFactoryBean contains a single constructor that requires two parameters, the Class for repository interface and nrich-search specific RepositoryFactorySupportFactory instance. The problem is that Spring Data expects the class extended from RepositoryFactoryBeanSupport with the constructor with a single parameter - the Class of repository interface (see org.springframework.data.repository.config.RepositoryBeanDefinitionBuilder.build()). That leaves the
second constructor parameter unresolved when the corresponding bean definition is created during the initialization of Spring's bean factory.

In some cases, this works, but if any of beanFactory.getBean() methods are called during bean factory initialization, creation of all defined beans is triggered. If we have a bean definition with unresolved constructor parameters at this point, Spring throws UnsatisfiedDependencyException complaining about ambiguous constructor argument values.

Steps to reproduce

In this case, above behavior is triggered from Axon Framework's AbstractQualifiedBeanCondition.getMatchOutcome() method, which calls beanFactory.getBeanNamesForType().

Expected behavior

The SearchExecutorJpaRepositoryFactoryBean initialization does not fail when beanFactory.getBean() methods are called during beanFactory initialization.

Actual behavior

The SearchExecutorJpaRepositoryFactoryBean initialization fails when beanFactory.getBean() methods are called during beanFactory initialization

Basic information

• nrich version:
  1.2.1
• Module:
  project

Additional information

Enhancement description

At the moment, source files don't contain licence header, e.g. Spring.

Current behaviour

There are no licence headers in any source files.

Wanted behaviour

There should be same licence header in all source files.

Possible workarounds

Basic information

• nrich version:
  1.2.1
• Module:
  nrich-registry

Additional information

Enhancement description

Currently the returned values for form label and column header in registry configuration start with lowercase. It would be good for them to start with uppercase so users don't have to override those values and can use the default configuration.

Current behaviour

formLabel, columnHeader start with lowercase.

Wanted behaviour

formLabel, columnHeader start with uppercase.

Possible workarounds

Basic information

• nrich version:
  1.2.1
• Module:
  nrich-search
• Link to the complete executable reproducer if available (e.g. GitHub Repo):

Additional information

Bug description

When property being searched is of Instant type no matter which format is sent it doesn't work. Also just in case check other date types as well.

Steps to reproduce

Expected behavior

Users are able to search Instants.

Actual behavior

Users are unable to search Instants.

Basic information

• nrich version:
  1.2.1
• Module:
  nrich-notification, nrich-validation

Additional information

Enhancement description

Currently the files that contain messages are called notificationMessages and validationMessages. Change camel case to kebab case and add nrich prefix. The new names should be nrich-notification-messages and nrich-validation-messages

Current behaviour

Wanted behaviour

Possible workarounds

Basic information

• nrich version:
  1.1.1
• Module:
  Project

Additional information

Enhancement description

Upgrade dependencies of all libraries to latest versions, possibly refactor code to match the new versions used (remove deprecated code etc).

Current behaviour

Used dependencies are outdated.

Wanted behaviour

The dependencies used are the latest versions.

Possible workarounds

Basic information

• nrich version:
  1.2.1
• Module:
  nrich-notification

Additional information

Enhancement description

Currently notification services have generics that make them hard to use, the default provided bean is of type NotificationResponseService<ResponseWithNotification<?>> that then causes sonar warning and requires casts to be able to use effectively, this should be refactored in a way that avoids wildcards.

Current behaviour

Wildcards in NotificationResponseService type parameters.

Wanted behaviour

No wildcards in NotificationResponseService type parameters.

Possible workarounds

Basic information

• nrich version:
  1.2.1
• Module:
  nrich-search

Additional information

Enhancement description

It would be good that searching by prefix supports any level of nested path, currently only the first level is checked (i.e. properties contained in the parent object).

Current behaviour

Only properties found in the parent can be found by prefix search.

Wanted behaviour

Properties found in the any level of nesting can be found by prefix search.

Possible workarounds

Basic information

• nrich version: 1.2.1
• Module: project

Additional information

Enhancement description

We should upgrade Spring Boot (i.e. Spring Framework) to the latest release, as a new CVE was found recently.

Update Spring Boot version to 2.6.5 to fix this issue.

Current behaviour

Expression DoS Vulnerability present in project, transitively, via old Spring version.

Wanted behaviour

Expression DoS Vulnerability not present in project after upgrading to newest Spring version.

Possible workarounds

Basic information

• nrich version: v1.3.0
• Module: nrich-excel, nrich-excel-spring-boot-starter

Additional information

Enhancement description

We should upgrade the Apache POI library to the latest stable version (5.2.2 at the time of opening this issue) as a "medium level" vulnerability was found in version 5.2.0.

Current behaviour

Vulnerability present in project, transitively, via Apache POI version 5.2.0.

Wanted behaviour

Vulnerability not present in project after upgrading Apache POI to latest version.

Possible workarounds

Basic information

• nrich version:
  1.1.1
• Module:
  Project

Additional information

Enhancement description

Currently there is no editorconfig in the project which makes it harder to keep coding style in check.
It would be best to add the editorconfig, reformat all the source files and align other coding style differences if they are found. Also in scope of this it would be good to remove the final modifier on parameters and local variables since reduces readability.

Current behaviour

Wanted behaviour

Possible workarounds

Basic information

• nrich version:
  1.2.1
• Module:
  nrich-excel

Additional information

Enhancement description

Current documentation for pagination using MultiRowDataProvider and Spring Data Jpa repository is not correct, start is passed in as page number but start in MultiRowDataProvider is not the same as page number.

Current behaviour

Documentation incorrectly describes usage of MultiRowDataProvider.

Wanted behaviour

Documentation correctly describes usage of MultiRowDataProvider.

Possible workarounds

Basic information

• nrich version: v1.3.0
• Module: project

Additional information

Update url in main README to https://croz-ltd.github.io/nrich .

Bug description

Github Pages Javadoc badge link broken.

Steps to reproduce

Expected behaviour

Github Pages Javadoc badge link works.

Actual behaviour

Github Pages Javadoc badge link broken.

Basic information

• nrich version:
  1.2.1
• Module:
  project

Additional information

Enhancement description

At the moment, the only way to learn Nrich is by reading documentation and source code. It would be useful to have example applications which would showcase Nrich features by example.

Current behaviour

Wanted behaviour

Possible workarounds

Basic information

• nrich version:
  1.2.1
• Module:
  Project

Additional information

Enhancement description

Some modules currently display following messages during startup:

Bean ... of type ... is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)

it would be good to check those messages and if there are some issues behind them solve them.

Current behaviour

Messages: "Bean ... of type ... is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)" shown on startup.

Wanted behaviour

Ideally no messages like "Bean ... of type ... is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)" shown on application startup.

Possible workarounds

Basic information

• nrich version:
  1.2.1
• Module:
  nrich-spring-util

Additional information

Enhancement description

The name for nrich-spring-util is not inline with nrich-spring-boot it would be better to remove the util suffix.

Current behaviour

Module is named nrich-spring-util.

Wanted behaviour

Module is named nrich-spring.

Possible workarounds

Basic information

• nrich version:
  1.2.1
• Module:
  nrich-form-configuration-spring-boot-starter

Additional information

Enhancement description

Currently to specify mapping between formId and class that holds the validations for that formId users need to specify a bean of type Map<String, Class<?>> that doesn't seem to be inline with rest of the projects, it would be better to allow specifying through properties file.

Current behaviour

Users need to define a bean with configuration mapping.

Wanted behaviour

Users can specify mapping using properties file.

Possible workarounds

Basic information

• nrich version:
  1.2.1
• Module:
  project

Additional information

Enhancement description

In real world, in most cases users would probably use Nrich with some frontend. After #55, it would be useful to have example frontend application which would showcase some Nrich features by example.

Current behaviour

Wanted behaviour

Possible workarounds

Basic information

• nrich version:
  1.1.1
• Module:
  Project

Additional information

Enhancement description

The continuation indent of 8 seems a bit too much, switch to using continuation indent to 4 and reformat code to match this change. There also seems to be some lines longer than 200 character, add line breaks where needed. Reformat AutoConfiguration tests to have asserts in a separate line. Remove extra empty lines where applicable. Order Lombok annotations and use minimal set. Introduce constants where missing.

Current behaviour

Wanted behaviour

Possible workarounds

Basic information

• nrich version:
  1.2.1
• Module:
  nrich-registry

Additional information

Enhancement description

Currently to specify registry configuration users need to define a bean of RegistryConfiguration that doesn't seem to be inline with rest of the projects, it would be better to allow specifying through properties file.

Current behaviour

Users need to define a bean with registry configuration.

Wanted behaviour

Users can specify configuration using properties file.

Possible workarounds

Basic information

• nrich version:
  1.2.1
• Module:
  nrich-registry

Additional information

Enhancement description

Currently the returned value for javascriptType in registry configuration is in uppercase (i.e. NUMBER, STRING) since those types in Javascript are all lowercase it would be good to match that.

Current behaviour

javascriptType for properties in RegistryConfiguration is in uppercase.

Wanted behaviour

javascriptType for properties in RegistryConfiguration is in lowercase.

Possible workarounds

Basic information

• nrich version:
  1.1.1
• Module:
  Project

Additional information

Enhancement description

It would be good to reduce number of sonar issues, some might be invalid others not possible to fix (at least easily) so it is not necessary to fix all the issues just the ones that make sense.

Current behaviour

Sonar reports issues that can be easily fixed.

Wanted behaviour

Sonar reported issues that can be fixed are fixed.

Possible workarounds

Ignore sonar issues.

Basic information

• nrich version:
  1.2.1
• Module:
  Project

Additional information

Enhancement description

Currently all our modules have same description it would be better that they all have their individual descriptions.

Current behaviour

All modules have the same description.

Wanted behaviour

Each module has unique description.

Possible workarounds

Basic information

• nrich version:
  1.4.1
• Module:
  nrich-search

Additional information

Enhancement description

When creating query from a collection of values in case the collection is empty it should be skipped since it makes no sense to search by empty collection.

Current behaviour

Request with empty collection results in a query that never returns any value.

Wanted behaviour

Empty collection should be skipped when creating a query.

Possible workarounds

Basic information

• nrich version: v1.2.1
• Module: project

Additional information

Enhancement description

The root gradle project name is currently defined as "nrichcode" in settings.gradle. Rename to "nrich" as "nrichcode" is the old legacy name of the project.

Current behaviour

Root gradle project is named "nrichcode".

Wanted behaviour

Root gradle project is named "nrich".

Possible workarounds

Basic information

• nrich version:
  1.2.1
• Module:
  nrich-excel

Additional information

Enhancement description

It would be good for nrich-excel to work with OutputStream instead of using File as input. Not all users need a File created and this would make API more flexible.

Current behaviour

ExcelReportService accepts a File inside CreateExcelReportRequest argument of createExcelReport method.

Wanted behaviour

ExcelReportService accepts an OutputStream inside CreateExcelReportRequest argument of createExcelReport method.

Possible workarounds

Discussed in #122

Basic information

• nrich version: 1.4.1
• Module: nrich-form-configuration

Additional information

Enhancement description

Add a class annotation for defining form id.
The proposed name for the annotation is @FormConfiguration.
Both ways would be supported, defining mappings through property files and using the annotation.
If both are used, the property file would take precedence.

Current behaviour

Mappings between form id and corrresponding clases have to be defined in a property file.

nrich.form-configuration:
  default-converter-enabled: true
  form-configuration-mapping:
    user.create-form: net.croz.nrich.example.CreateUserRequest
    user.update-form: net.croz.nrich.example.UpdateUserRequest

Wanted behaviour

Use annotation to define form id.

@FormConfiguration("user.create-form")
public class CreateUserRequest {
   ...
}

Basic information

• nrich version:
  1.2.1
• Module:
  nrich-form-configuration

Additional information

Enhancement description

Current behaviour

No test for FormConfigurationController

Wanted behaviour

Test exists for FormConfigurationController

Possible workarounds

Basic information

• nrich version:
  1.2.1
• Module:
  project

Additional information

Enhancement description

It would be useful for users to document which Nrich major versions are compatible with which Java and Spring/Spring Boot versions.

Current behaviour

Wanted behaviour

Possible workarounds

Basic information

• nrich version: 1.2.1
• Module: project

Additional information

Enhancement description

Remove 3rd party Gradle plugin org.kordamp.gradle.jacoco introduced in #25 and replace with new internal plugin introduced in Gradle 7.4.

Current behaviour

3rd party Gradle plugin org.kordamp.gradle.jacoco used for aggregated test reports.

Wanted behaviour

3rd party Gradle plugin org.kordamp.gradle.jacoco not used for aggregated test reports, as there is an internal Gradle plugin present now.

Possible workarounds

Basic information

• nrich version:
  1.2.1
• Module:
  nrich-search

Additional information

Enhancement description

It would be good to find a way to optimise query creation in nrich-search module. Currently each query will always check all properties being searched against entity. It would be better to analyse just once all the possible mappings between class holding restrictions and JPA entity and then cache and reuse those mappings depending on the property values.

Current behaviour

Wanted behaviour

Possible workarounds

Basic information

• nrich version:
  1.2.0
• Module:
  Project

Additional information

Enhancement description

We would like a way of tracking our architecture decisions in the project as to make onboarding of new developers easier
and keep track of important changes inside the project.

Current behaviour

No explanation of the current architecture exists.

Wanted behaviour

A list of architecture decision records exists explaining the current state of project. All future decisions are also recorded.

Possible workarounds

Basic information

• nrich version:
  1.2.0
• Module:
  nrich-excel

Additional information

Enhancement description

Currently when users want to export data to excel they always need to implement a MultiRowDataProvider interface, when users have just flat data that is cumbersome, it would be better to provide a simpler API for flat data.

Current behaviour

When providing flat data users need to provide a MultiRowDataProvider implementation i.e.

  Object[][] data = new Object[][] { { "firstRow" }, { "secondRow" } };  

  MultiRowDataProvider multiRowDataProvider = (start, limit) -> start == 0 ? data :  null; 

Wanted behaviour

Skip users creation of MultiRowDataProvider and add a property to CreateExcelReportRequest that supports flat data.

Possible workarounds

Basic information

• nrich version:
  1.2.1
• Module:
  nrich-logging

Additional information

Enhancement description

It would be useful to have a starter module for nrich-logging, most of the others have them this one seems to be an exception.

Current behaviour

No Spring Boot starter module present for nrich-logging.

Wanted behaviour

Spring Boot starter module present for nrich-logging.

Possible workarounds

Basic information

• nrich version:
  1.3.0
• Module:
  nrich-search

Additional information

Feature description

It would be useful to add support for searching by @naturalid annotated properties, it provides better caching than usual query cache. This is only possible with Hibernate JPA provider. It would be best to add another repository interface that users can use to add desired functionality. For details see: https://vladmihalcea.com/the-best-way-to-map-a-naturalid-business-key-with-jpa-and-hibernate/

Current behavior

No support for searching by @naturalid annotated properties.

Wanted behavior

Searching by @naturalid annotated properties works.

Possible workarounds

Basic information

• nrich version:
  1.2.0
• Module:
  Project

Additional information

Feature description

It would be good to have a bom/platform module that will provide all nrich dependencies as a bom and allow users to use that
for dependency version management./

Current behavior

Users need to include versions for each dependency added.

Wanted behavior

Users import bom/platform module and use the dependency versions defined there.

Possible workarounds

Basic information

• nrich version: v1.2.1
• Module: project

Additional information

Enhancement description

Enhance existing README files by adding information regarding the

• process of releasing new versions of our libraries
• publishing process (to Maven Central)
• more generally, information about configured GitHub actions

Note: this issue should be worked on after #58, as there will be changes to the release/publish process and some actions.

Current behaviour

Missing documentation regarding the release/publish process, and all configured GitHub actions.

Wanted behaviour

Documentation regarding the release/publish process, and all configured GitHub actions added.

Possible workarounds

Basic information

• nrich version:
  1.2.1
• Module:
  nrich-search

Additional information

Feature description

Currently in StringSearchExecutor it is not possible to search by ranges i.e. dateFrom, dateTo, numberFrom, numberTo etc as it is in SearchExecutor. It would be good to add that functionality from SearchExecutor to StringSearchExecutor

Current behavior

Range queries are not supported.

Wanted behavior

Range queries are supported.

Possible workarounds

Using custom SearchConfiguration

Basic information

• nrich version:
  1.2.1
• Module:
  nrich-webmvc

Additional information

Enhancement description

Currently for caching in DefaultTransientPropertyResolverService a ConcurrentHashMap is used. It would be better to use @Cacheable annotation to allow users to configure caching and avoid potential memory issues.

Current behaviour

ConcurrentHashMap is used for caching.

Wanted behaviour

@Cacheable annotation is used for caching

Possible workarounds

Basic information

• nrich version: 1.2.0
• Module: project

Additional information

Enhancement description

• Add org.kordamp.gradle.jacoco plugin to have aggregated test reports
• Add code coverage report integration with app.codecov.io
• Add codecov GitHub badge

Current behaviour

No code coverage visualisation tool integrated.

Wanted behaviour

Code coverage visualisation tool (app.codecov.io) integrated.

Possible workarounds

Basic information

• nrich version:
  1.1.1
• Module:
  Project

Additional information

Enhancement description

Currently in tests there is only a warning logged about missing logger implementation, it would be better to add a logger implementation at least in the test scope.

Current behaviour

No logs in tests.

Wanted behaviour

Logs in tests visible.

Possible workarounds

Basic information

• nrich version: v1.4.0
• Module: project

Additional information

Enhancement description

We would like to enhance the codecov configuration as currently, only the default codecov behaviour applies.
We would like to have checks that explicitly check whether

1. the code/line coverage is above 95%, on the changed code (patch status) and on the whole project (project status)
2. (if configurable) the branch coverage/code complexity

Current behaviour

Default codecov behaviour.

Wanted behaviour

Minimum code coverage explicitly configured.

Possible workarounds

Basic information

• nrich version: v1.2.1
• Module: project

Additional information

Enhancement description

We want to enhance the release process of our libraries, in a way that a release can be automatically triggered with a GitHub Action. We could replace the existing "Publish" action with a new "Release" action which would both generate a GitHub release and publish the artifacts to Maven Central. Also, we would like to enhance/beautify the changelog generation for releases, and JReleaser seems like the perfect fit.

Current behaviour

• Default GitHub release changelog generator
• No automatic release process via GitHub actions, releases have to be created manually

Wanted behaviour

• Enhanced GitHub release changelog generator via JReleaser
• Automatic release process via GitHub actions using JReleaser, no need for manual release creation

Possible workarounds

Basic information

• nrich version:
  1.2.1
• Module:
  Project
• Link to the complete executable reproducer if available (e.g. GitHub Repo):

Additional information

Bug description

It seems that not all projects declare required dependencies while other have extra dependencies, they should all just use a minimal set off required dependencies. This has been seen in nrich-form-configuration module but would be best to go through all the modules.

Steps to reproduce

Add each of the modules and see if they can be run without additional configuration. It would be best to use "pure" Spring project because Spring Boot will probably cover all the dependencies.

Expected behavior

All modules work without adding additional dependencies manually .

Actual behavior

Not all modules work without adding additional dependencies.